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Отзывы о книге 


«Мы живем во время, когда, как это ни удивительно, только начинают 
появляться самые лучшие печатные работы по С++. Эта книга — одна из 
них. Хотя С++ стоит в авангарде нововведений и продуктивности разра- 
ботки программного обеспечения более двух десятилетий, только сейчас 
мы достигли полного его понимания и использования. Данная книга — 
это один из тех редких вкладов, ценный как для практиков, так и для 
теоретиков. Это не трактат тайных или академических знаний. Скорее, 
книга дает доскональное описание известных, казалось бы, вещей, недо- 
понимание которых рано или поздно даст о себе знать. Очень немногие 
овладели С++ и проектированием программного обеспечения так, как это 
сделал Стив. Практически никто не обладает такой рассудительностью 
и спокойствием, когда речь идет о разработке программного обеспечения. 
Он знает, что необходимо знать, поверьте мне. Когда он говорит, я всегда 
внимательно слушаю. Советую и вам делать так же. Вы (и ваши заказчи- 
ки) будете благодарны за это.» 


Чак Эллисон (СһисЕ АШізѕоп ), 
редактор журнала «Тһе С++ боигсе» 


«Стив обучил меня С++. Это было в далеком 1982 или 1983. Я думаю, он 
тогда только вернулся с последипломной практики, которую проходил 
вместе с Бьерном Страуструпом (Вјагпе Ѕігоиѕігир) [создателем С++] 
в научно-исследовательском центре Ве! Іађогаќогіеѕ. Стив – один из не- 
воспетых героев, стоящих у истоков. Все, что им написано, я отношу 
к обязательному и первоочередному чтению. Эта книга легко читается, 
она вобрала в себя большую часть обширных знаний и опыта Стива. На- 
стоятельно рекомендую с ней ознакомиться.» 


Стен Липман (ап Гірртап ), 
соавтор книги «С++ Ргітег, Гоитй Ейііоп» 
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«Я приветствую обдуманный профессиональный подход коротких и тол- 
ковых книг.» 


Мэтью П. Джонсон (Май йе Р. Јоћпѕоп), 
Колумбийский университет 


«Согласен с классификацией программистов [сделанной автором]. В сво- 
ей практике разработчика мне доводилось встречаться с подобными 
людьми. Эта книга должна помочь им заполнить пробел в образовании... 
Я думаю, данная книга дополняет другие, такие как «ЕЁесйуе С++» 
Скотта Мейерса (3со$ Меуегз). Вся информация в ней представлена крат- 
ко и проста для восприятия.» 


Моутаз Кэмел (Моаіаг Кате), ведущий разработчик 
программного обеспечения, компания Моїіогоіа, Канада 


«Дъюхерст написал еще одну очень хорошую книгу. Она необходима лю- 
дям, использующим С++ (и думающим, что они уже все знают о С++). » 


Кловис Тондо (С1Іоріѕ Топӣо ), 
соавтор книги «С++ Ргітег Апѕшег ВооЁ» 


Предисловие 


Успешность книги определяется не ее содержанием, 
а тем, что осталось вне ее рассмотрения. 


Марк Твен 


..просто, насколько возможно, но не проще. 


Альберт Эйнштейн 


писатель, ставящий под вопрос 
умственные способности читателя, 
вообще не писатель, а просто прожектер. 


Е. В. Уайт 


Заняв должность редактора ныне закрывшегося журнала «С++ Берогі», 
непоседливый Герб Саттер (Негр Ѕиіїег) предложил мне вести колонку 
и выбрать тему на мое усмотрение. Я согласился и решил назвать колон- 
ку «Общее знание». Герб представлял эту колонку как «систематический 
обзор основных профессиональных знаний, которыми должен распола- 
гать каждый практикующий программист на С++». Однако, сделав пару 
выпусков в этом ключе, я заинтересовался методиками метапрограмми- 
рования шаблонов, и темы, рассматриваемые в «Общем знании», с этого 
момента стали далеко не такими «общими». 


Проблема индустрии программирования на С++, обусловившая выбор те- 
мы, осталась. В своей практике преподавателя и консультанта я сталки- 
ваюсь со следующими типами личностей: 


® программисты, в совершенстве владеющие С, но имеющие только ба- 
зовые знания С++ и, возможно, некоторую неприязнь к нему; 
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® талантливые новобранцы, прямо с университетской скамьи, имеющие 
глубокую теоретическую подготовку в С++, но небольшой опыт рабо- 
ты с этим языком; 


• высококвалифицированные Јауа-программисты, имеющие небольшой 
опыт работы с С++ и склонные программировать на С++ в стиле Јауа; 


• программисты на С++ с опытом сопровождения готовых приложений 
на С++, у которых не было необходимости изучать что-либо сверх то- 
го, что требуется для сопровождения кода. 


Хотелось бы сразу перейти к делу, но многим из тех, с кем я сотрудничаю 
или кого обучаю, требуется предварительное изучение различных воз- 
можностей языка программирования С++, шаблонов и методик написа- 
ния кода. Хуже того, я подозреваю, что большая часть кода на С++ напи- 
сана в неведении о некоторых из этих основ и, следовательно, не может 
быть признана специалистами качественным продуктом. 


Данная книга направлена на решение этой всепроникающей проблемы. 
В ней основные знания, которыми должен обладать каждый профессио- 
нальный программист на С++, представлены в такой форме, что могут 
быть эффективно и четко усвоены. Значительная часть материала доступ- 
на в других источниках или уже входит в неписаные рекомендации, из- 
вестные всем экспертам в С++. Преимущество книги в том, что вся ин- 
формация, в отборе которой я руководствовался своим многолетним опы- 
том преподавания и консультирования, расположена компактно. 


Очень может быть, что самое важное в шестидесяти трех коротких темах, 
составляющих данную книгу, заключается в том, что осталось вне рас- 
смотрения, а не в том, что они содержат. Многие из этих вопросов потен- 
циально очень сложны. Если бы автор не был осведомлен об этих сложно- 
стях, то недостоверные сведения ввели бы читателя в заблуждение; в то 
же время профессиональное обсуждение вопроса с полным представлени- 
ем всех сложных аспектов могло бы его запутать. Все слишком сложные 
вопросы были отсеяны. Надеюсь, то, что осталось, представляет собой 
квинтэссенцию знаний, необходимых для продуктивного программиро- 
вания на С++. Знатоки заметят, что я не рассматриваю некоторые вопро- 
сы, интересные и даже важные с теоретической точки зрения, незнание 
которых, однако, как правило, не влияет на способность читать и писать 
код на С++. 


Другим толчком для написания данной книги стала моя беседа с группой 
известных экспертов в С++ на одной из конференций. Все они были на- 
строены мрачно, считая современный С++ слишком сложным и потому 
недоступным для понимания «среднестатистическим» программистом. 
(Конкретно речь шла о связывании имен в контексте шаблонов и про- 
странств имен. Да, если ты раздражаешься по такому поводу, значит, пора 
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больше общаться с нормальными людьми.) Поразмыслив, должен ска- 
зать, что наша позиция была высокомерной, а пессимизм — неоправдан- 
ным. У нас, «экспертов», нет таких проблем, и программировать на С++ 
так же просто, как говорить на (намного более сложном) естественном 
языке, даже если ты не можешь схематически представить глубинную 
структуру каждого своего высказывания. Основная идея данной книги: 
даже если полное описание нюансов конкретной возможности языка вы- 
глядит устрашающе, ее рутинное использование вполне может быть бес- 
хитростным и естественным. 


Возьмем перегрузку функций. Полное описание занимает немалую часть 
стандарта и одну или несколько глав многих учебников по С++. И тем не 
менее, столкнувшись с таким кодом 


уоіа #( іпї ); 
үоіа #( сопѕї сһаг * ); 


//.. 
РО "Не110" ); 


любой практикующий программист на С++ безошибочно определит, ка- 
кая Г вызывается. Знание всех правил разрешения вызова перегружен- 
ной функции полезно, но очень редко бывает необходимым. То же самое 
можно сказать о многих других якобы сложных областях и идиомах язы- 
ка программирования С++. 


Сказанное не означает, что вся книга проста; «она проста настолько, на- 
сколько это возможно, но не проще». В программировании на С++, как 
в любой другой достойной внимания интеллектуальной деятельности, 
многие важные детали нельзя уместить на карточке картотеки. Более то- 
го, эта книга не для «чайников». Я чувствую огромную ответственность 
перед теми, кто тратит свое драгоценное время на чтение моих книг. Я ува- 
жаю этих людей и стараюсь общаться с ними как с коллегами. Нельзя пи- 
сать для профессионалов, как для восьмиклассников, потому что это чис- 
тая профанация. 


Многие темы книги опровергают заблуждения, с которыми я многократ- 
но сталкивался и на которые просто надо обратить внимание (например, 
посвященные порядку областей видимости при поиске функции-члена, 
разнице между переопределением и перегрузкой). В других обсуждаются 
вопросы, знание которых постепенно становится обязательным для про- 
фессионалов С++, но нередко ошибочно считающиеся сложными и пото- 
му замалчиваемые (например, частичная специализация шаблонов клас- 
са и параметры-шаблоны шаблонов). Я был раскритикован экспертами, 
рецензировавшими рукопись этой книги, за то, что слишком много вни- 
мания (примерно треть книги) уделил вопросам шаблонов, которые не от- 
носятся к общим знаниям. Однако каждый из этих специалистов указал 
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один, два и более вопросов по шаблонам, которые, по их мнению, следова- 
ло включить в книгу. Примечательно то, что предлагаемые ими вопросы 
немного перекрывались. В итоге каждый из рассмотренных мною аспек- 
тов шаблонов получил, по крайней мере, одного сторонника. 


В этом и состояла главная трудность отбора тем для данной книги. Вряд 
ли найдутся читатели, абсолютно не сведущие ни в одном из рассматри- 
ваемых вопросов. Скорее всего, некоторым из них будет хорошо знаком 
весь материал. Очевидно, что если читатель не знает конкретной темы, то 
ему было бы полезно (я так думаю) изучить ее. Но рассмотрение даже зна- 
комого вопроса под новым углом способно развеять некоторые заблужде- 
ния или помочь глубже понять вопрос. А более опытным программистам 
на С++ книга поможет сберечь драгоценное время, которое они нередко 
вынуждены (как уже отмечалось) отрывать от своей работы, без конца от- 
вечая на одни и те же вопросы. Я предлагаю интересующимся сначала 
прочитать книгу, а потом спрашивать, и думаю, что это поможет напра- 
вить усилия специалистов на решение сложных проблем, туда, где это 
действительно необходимо. 


Сначала я пытался четко сгруппировать шестьдесят три темы в главы, но 
испытал неожиданные затруднения. Темы стали объединяться самоволь- 
но — иногда вполне предсказуемо, а иногда совершенно неожиданным об- 
разом. Например, темы, посвященные исключениям и управлению ре- 
сурсами, образуют довольно естественную группу. Взаимосвязь тем «За- 
просы возможностей», «Смысл сравнения указателей», «Виртуальные 
конструкторы и Прототип», «Фабричный метод» и «Ковариантные воз- 
вращаемые типы» хотя и тесна, но несколько неожиданна. «Арифметику 
указателей» я решил представить вместе с «Умными указателями», а не 
с изложенным ранее материалом по указателям и массивам. Вместо того 
чтобы навязать жесткую группировку тем по главам, я предоставил чита- 
телю свободу ассоциации. Конечно, между темами, которые могли бы 
быть расположены в простом линейном порядке, существует масса других 
взаимосвязей, поэтому в темах делается множество внутренних ссылок 
друг на друга. Это разбитое на группы, но взаимосвязанное сообщество. 


Хотя основной идеей книги является краткость, обсуждение темы иногда 
включает дополнительные детали, не касающиеся непосредственно рас- 
сматриваемого вопроса. Эти подробности не всегда относятся к теме дис- 
куссии, но читателю сообщается об определенной возможности или мето- 
дике. Например, шаблон Неар, появляющийся в нескольких темах, мимо- 
ходом информирует читателя о существовании полезных, но редко рас- 
сматриваемых алгоритмов ТІ, работы с кучей. Обсуждение синтаксиса 
размещения пем представляет техническую базу сложных методик управ- 
ления буферами, широко используемых стандартной библиотекой. Так- 
же везде, где это казалось уместным, я пытался включить обсуждение 
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вспомогательных вопросов в рассмотрение конкретной проблемы. Поэто- 
му тема «Методика КАП» содержит краткое обсуждение порядка вызова 
конструктора и деструктора, в теме «Логический вывод аргументов шаб- 
лона» обсуждается применение вспомогательных функций для специа- 
лизации шаблонов классов, а «Присваивание и инициализация - не одно 
и то же» включает рассмотрение вычислительных конструкторов. В этой 
книге запросто могло бы быть в два раза больше тем. Но и группировка 
самих тем, и связь вспомогательных вопросов с конкретной темой поме- 
щают проблему в контекст и помогают читателю эффективно усваивать 
материал. 


Я с неохотой включил несколько вопросов, которые не могут быть рас- 
смотрены корректно в формате коротких тем, принятом в данной книге. 
В частности, вопросы шаблонов проектирования и проектирования стан- 
дартной библиотеки шаблонов представлены смехотворно кратко и непол- 
но. Но все же они вошли сюда, просто чтобы положить конец некоторым 
распространенным заблуждениям, подчеркнуть свою важность и подтолк- 
нуть читателя к более глубокому изучению. 


Традиционные примеры являются частью нашей культуры программи- 
рования, как истории, которые рассказывают на семейных праздниках. 
Поэтому здесь появляются Ѕһаре, 51г1пд, Этаск и далее по списку. Всеоб- 
щее понимание этих базовых примеров обеспечивает тот же эффект при 
общении, что и паттерны проектирования. Например, «Предположим, 
я хочу вращать Ѕһаре, кроме...» или «При конкатенации двух 51г1190...». 
Простое упоминание обычного примера определяет направление беседы 
и устраняет необходимость длительного обсуждения предпосылок. 


В отличие от моей предыдущей книги, здесь я пытаюсь избегать критики 
плохих практик программирования и неверного использования возмож- 
ностей языка С++. Пусть этим занимаются другие книги, лучшие из ко- 
торых я привел в списке литературы. (Однако мне не вполне удалось из- 
бежать менторского тона; некоторые плохие практики программирова- 
ния просто необходимо упомянуть, хотя бы вскользь.) Цель данной кни- 
ги – рассказать читателю о технической сущности производственного 
программирования на С++ максимально эффективным способом. 


Стивен С. Дьюхерст, 
Карвер, Массачусетс, январь 2005 
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Принятые обозначения 


Как упоминалось в предисловии, в этой книге много перекрестных ссылок. 
При ссылке на какую-либо тему приводится и ее номер, и полное назва- 
ние, чтобы читателю не приходилось постоянно сверяться с оглавлением 
с целью понять, чему посвящена данная тема. Например, ссылка «64 
„Ешьте свои овощи“» говорит нам, что тема под названием «Ешьте свои 
овощи» имеет порядковый номер 64. 


Примеры кода выделены моноширинным шрифтом, чтобы их можно бы- 
ло отличить от остального текста. Примеры неверного или нерекомендуе- 
мого кода выделены серым фоном. Код без ошибок представлен без фона. 


Тема 1 | Абстракция данных 


Для программиста тип данных - это набор операций, а абстрактный 
тип - это набор операций с реализацией. Идентифицируя объекты 
в предметной области, мы прежде всего должны интересоваться, что 
можно сделать с помощью этого объекта, а не как он реализован. Следо- 
вательно, если в описании задачи присутствуют служащие, контракты 
и платежные ведомости, то выбранный язык программирования должен 
содержать типы Епр1оуее (Служащий), Сопігасі (Контракт) и Рауго1 1Весога 
(Платежная ведомость). Тем самым обеспечивается эффективная двусто- 
ронняя трансляция между предметной областью и областью решения. 
Код, написанный таким образом, содержит меньше «трансляционного 
шума», он проще и в нем меньше ошибок. 


В языках программирования общего назначения, к которым относится 
С++, нет специальных типов, таких как Епр1оуее. Зато есть кое-что получ- 
ше, а именно средства для создания сложных абстрактных типов данных. 
По сути, назначение абстрактного типа данных состоит в расширении 
языка программирования в соответствии с нуждами конкретной пред- 
метной области. 


В С++ нет универсальной процедуры проектирования абстрактных типов 
данных. В этой области программирования все еще есть место для творче- 
ства и вдохновения. Однако самые успешные подходы подразумевают 
выполнение похожих шагов. 


1. Типу присваивается описательное имя. Если найти имя трудно, зна- 
чит, нет достаточной информации о том, что именно предполагается 
реализовывать. Необходим дополнительный анализ. Абстрактный тип 
данных должен представлять одно четко определенное понятие, и имя 
этого понятия должно быть очевидным. 
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2. 


Перечисляются операции, которые может осуществлять тип. Абст- 
рактный тип данных определяется тем, что можно сделать с его помо- 
щью. Нельзя забывать об инициализации (конструкторы), очистке ре- 
сурсов (деструктор), копировании (операции копирования) и преобра- 
зованиях (неявные конструкторы с одним аргументом и операторы 
преобразования). Ни в коем случае нельзя просто определять набор 
операций #е$/зеф над элементами данных реализации. Это не абстрак- 
ция данных, а лень и недостаток воображения. 


Проектируется интерфейс типа. Как говорит Скотт Мейерс (бсо Меу- 
егѕ), тип должен «помогать программировать правильно и мешать 
программировать неправильно». Абстрактный тип данных расширяет 
язык программирования. По сути, надо спроектировать язык. Попро- 
буйте поставить себя на место пользователя этого типа и напишите не- 
много кода, задействовав свой интерфейс. Правильная конструкция 
интерфейса — это вопрос как психологии и взаимопонимания, так 
и проявления технического мастерства. 


Тип реализуется. Реализация не должна оказывать влияние на интер- 
фейс типа. Должен реализовываться контракт, оговоренный интер- 
фейсом типа. Необходимо помнить, что реализации большинства абст- 
рактных типов данных будут меняться намного чаще, чем их интер- 
фейсы. 


Тема 2 | Полиморфизм 


В одних книгах по программированию полиморфизму приписывается 
мистический статус, другие о полиморфизме молчат вовсе, а на самом де- 
ле это простая и полезная концепция, поддерживаемая языком С++. Со- 
гласно стандарту полиморфный тип - это класс, имеющий виртуальную 
функцию. С точки зрения проектирования полиморфный объект — это 
объект, имеющий более одного типа. И полиморфный базовый класс - это 
базовый класс, спроектированный для использования полиморфными 
объектами. 


Рассмотрим тип финансового опциона Ап0рііоп (Американский опцион), 
представленный на рис. 2.1. 


У объекта Ап0рїіоп четыре типа: он одновременно выступает в ипостасях 
АтОр+іоп, Ортіоп (Опцион), 0еа1 (Сделка) и Ргісеар1е (Подлежащий оплате). 


деа1 РгісеарІе 


Орт1оп 


АпОр+1оп ЕигОрї1іоп 


Рис. 2.1. Полиморфизм в иерархии финансового опциона. 
У Американского опциона четыре типа 
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Поскольку тип - это набор операций (см. темы 1 «Абстракция данных» 
и 27 «Запросы возможностей»), с объектом Ап0рїіоп можно работать по- 
средством одного из его четырех интерфейсов. Это означает, что объектом 
Ап0рїіоп может управлять код, написанный для интерфейсов Пеа1, Ргісе- 
ар1е и Орїіоп. Таким образом, реализация АпОрііоп может применять и по- 
вторно использовать весь этот код. Для полиморфного типа, такого как 
Ап0ртіоп, самым важным из наследуемого от базовых классов являются 
интерфейсы, а не реализации. Часто бывает желательно, чтобы базовый 
класс не включал ничего, кроме интерфейса (см. тему 27 «Запросы воз- 
можностей»). 


Конечно, здесь есть своя тонкость. Чтобы эта иерархия классов работала, 
полиморфный класс должен уметь замещать любой из своих базовых 
классов. Другими словами, если универсальный код, написанный для 
интерфейса 0р+іоп, получает объект Ап0рїіоп, этот объект должен вести се- 
бя как Орііоп! 


Речь идет не о том, что АпОрїіоп должен вести себя идентично 0рііоп. (Преж- 
де всего, многие операции базового класса 0рїіоп нередко представляют 
собой чисто виртуальные функции без реализации.) Лучше рассматри- 
вать полиморфный базовый класс (0рїіоп) как контракт. Базовый класс 
дает определенные обещания пользователям его интерфейса: сюда входят 
твердые синтаксические гарантии вызова определенных функций-членов 
с определенными типами аргументов, а также обещания, которые слож- 
нее проверить, касающиеся того, что на самом деле произойдет при вызо- 
ве конкретной функции-члена. Конкретные производные классы, такие 
как Ап0ртіоп и ЕигОр1оп (Европейский опцион), представляют собой суб- 
контракторы, которые реализуют контракт, устанавливаемый классом 
Ортіоп с его клиентами, как показано на рис. 2.2. 


код Орт1оп 
интерфейса са 
Орїіоп ргісе() 
ирда+е() 
АтОр+іоп ЕигОрііоп 


ргісе() ргісе() 


Рис. 2.2. Полиморфный контрактор и его субконтракторы. 
Базовый класс Орііоп определяет контракт 
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Например, если в классе 0р{1оп есть чисто виртуальная функция-член 
ргісе (цена), вычисляющая текущее значение 0рііоп, то оба класса, Ат0р- 
їјоп и Еџг0рїіоп, должны реализовывать эту функцию. Очевидно, что 
в этих двух типах 0рііоп ее поведение не будет идентичным, но она долж- 
на вычислять и возвращать цену, а не звонить по телефону или распеча- 
тывать файл. 


С другой стороны, если вызвать функцию рг1се двух разных интерфейсов 
одного объекта, результат должен быть одним и тем же. По сути, любой 
вызов должен быть связан с одной и той же функцией: 


АтОр+1іоп *Ч = пем Ат0рїіоп; 


Ор+іоп »*р = а; 
а->ргісе(); // если здесь вызывается Ат0рїіоп: : рг1се. .., 
р->ргісе(); // ...то же самое должно происходить здесь! 


Это логично. (Просто удивительно, но углубленные аспекты объектно- 
ориентированного программирования по большей части есть не что иное, 
как проявление здравого смысла, скрытое завесой синтаксиса.) Вопросы: 
«Каково текущее значение этого Американского опциона?» и «Каково те- 
кущее значение этого опциона?», по моему мнению, требовали бы одного 
ответа. 


Аналогичные рассуждения, конечно же, применимы и к невиртуальным 
функциям объектов: 


р->ирдаїе(); // если здесь вызывается Орііоп: : ирдате. .., 
а->ираа+е(); // ... то же самое должно происходить здесь! 


Контракт, предоставляемый базовым классом, — это то, что позволяет 
«полиморфному» коду интерфейса базового класса работать с конкретны- 
ми опционами, оставаясь при этом в полезном неведении об их существо- 
вании. Иначе говоря, полиморфный код может управлять объектами Ап- 
Ортіоп и Еџг0ртіоп, рассматривая их как объекты класса О0рііоп. Различные 
конкретные типы могут добавляться или удаляться без всякого воздейст- 
вия на универсальный код, который знает только о базовом классе О0рїіоп. 
Если в какой-то момент появится АѕіапОрііоп (Азиатский опцион), поли- 
морфный код, знающий только 0рїіоп, сможет работать с ним в блажен- 
ном неведении о его конкретном типе. И если позже этот класс исчезнет, 
его отсутствие не будет замечено. 


Справедливо и то, что конкретным типам опционов, таким как Ап0ртіоп 
и Еиг0рїіоп, необходимо знать только о базовых классах, чьи контракты 
они реализуют. Они не зависят от изменений универсального кода. 
В принципе базовый класс может знать только о себе. Практически кон- 
струкция его интерфейса будет учитывать требования предполагаемых 
пользователей. Он должен проектироваться таким образом, чтобы произ- 
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водные классы могли без труда проследить и реализовать его контракт 
(см. тему 22 «Шаблонный метод»). Однако у базового класса не должно 
быть никакой конкретной информации о любом из его производных клас- 
сов, потому что это неизбежно усложнит добавление или удаление произ- 
водных классов в иерархии. 


В объектно-ориентированном проектировании, как и в жизни, действует 
правило «много будешь знать — скоро состаришься» (см. также темы 29 
«Виртуальные конструкторы и Прототип» и 30 «Фабричный метод»). 


Тема З | Паттерны проектирования 


У тех, кто еще не знаком с паттернами проектирования, после краткого 
обзора данной темы может создаться впечатление, что паттерны проекти- 
рования - это либо маркетинговый прием, либо какая-то простая методи- 
ка написания кода, либо забава ученых, которым на самом деле надо по- 
чаще выходить прогуляться. Хотя во всем этом и есть некоторая доля ис- 
тины, паттерны проектирования — это важнейший компонент инстру- 
ментария профессионального программиста на С++. 


Паттерн проектирования - это многократно применяемая архитектур- 
ная конструкция, предоставляющая решение общей проблемы проекти- 
рования в рамках конкретного контекста и описывающая результат этого 
решения. Паттерн проектирования — это больше, чем простое описание 
техники. Это именованный блок конструкторской мудрости, накоплен- 
ной в результате успешного опыта, написанный таким образом, что он 
может без труда тиражироваться и повторно использоваться. Паттерны — 
это средство обмена информацией между разработчиками. 


Паттерны проектирования обладают двумя важными практическими 
свойствами. Во-первых, они описывают проверенную успешную методи- 
ку проектирования, которая может быть настроена соответственно кон- 
тексту новых ситуаций проектирования. Во-вторых, что еще важнее, вы- 
бор определенного паттерна говорит не только о выбранной технике, но 
и о причинах и следствиях ее применения. 


Здесь нет ничего нового. Рассмотрим аналогию из области алгоритмов. 
(Алгоритмы не являются ни паттернами проектирования, ни «паттерна- 
ми кода». Они всего лишь алгоритмы, поэтому мы и говорим об анало- 
гии.) Возьмем следующее высказывание, с которым я мог бы обратиться 
к коллегам: «У меня есть неотсортированная последовательность, по ко- 
торой необходимо проводить многократный поиск. Поэтому я собираюсь 
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осуществить быструю сортировку и каждую операцию поиска выполнять 
с помощью двоичного поиска». Возможность употребить термины «быст- 
рая сортировка» и «двоичный поиск» имеет неоценимое значение не толь- 
ко при проектировании, но и при общении с коллегами. Когда я говорю 
«быстрая сортировка», мой коллега знает, что сортируемая последова- 
тельность находится в структуре с произвольным доступом, которая, веро- 
ятнее всего, будет сортироваться до О(п15о п) раз, и что элементы последо- 
вательности могут сравниваться с помощью оператора, подобного операто- 
ру «меньше чем». Когда я говорю «двоичный поиск», мой коллега знает 
(даже если я ранее не упоминал о «быстрой сортировке»), что последова- 
тельность уже отсортирована, что я буду выявлять интересующий элемент 
с помощью 0(]5п) сравнений и что для сравнения элементов последова- 
тельности есть соответствующая операция. Общеизвестность и стандарт- 
ный словарь стандартных алгоритмов обеспечивают возможность не толь- 
ко эффективного документирования, но и эффективной критики. Напри- 
мер, если бы я запланировал проводить эту процедуру поиска и сортировки 
для однонаправленного списка, мой коллега немедленно ухмыльнулся 
бы и сказал, что я не могу применять быструю сортировку, да и двоичный 
поиск мне вряд ли нужен. 


«Допаттерная» эпоха в объектно-ориентированном проектировании ха- 
рактеризовалась тем, что не было тогда ни радостей эффективного доку- 
ментирования и общения, ни этих действенных саркастических улыбок. 
Приходилось пускаться в подробные описания своих проектов, мирясь 
с неэффективностью и неточностью, свойственным таким методам рабо- 
ты. И дело не в том, что не было правильных методик объектно-ориенти- 
рованного проектирования, — не было единой терминологии, способной 
сделать эти методики доступными всему сообществу разработчиков. Пат- 
терны проектирования решают эту проблему. Теперь объектно-ориенти- 
рованные проекты могут описываться так же эффективно и однозначно, 
как и алгоритмические. 


Например, когда мы видим, что в проекте применяется паттерн Мост 
(Ву195е), мы знаем, что на простом механическом уровне реализация аб- 
страктного типа данных была разделена на интерфейсный класс и класс 
реализации. Кроме того, известно, что это было сделано с целью строгого 
разделения интерфейса и реализации, чтобы изменения в реализации не 
отражались на пользователях интерфейса. Мы также знаем о существо- 
вании издержек времени выполнения, связанных с этим разделением, 
о том, как должен быть организован исходный код абстрактного типа дан- 
ных, и о многих других деталях. Имя паттерна - это эффективный, одно- 
значный дескриптор огромного объема информации и опыта. Правильное 
и аккуратное применение паттернов и их терминологии при проектирова- 
нии и документировании делает код и проекты более понятными. 
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Поклонники паттернов иногда описывают паттерны проектирования как 
своего рода литературный жанр (это действительно так), имеющий опре- 
деленную формальную структуру. В ходу несколько общих вариантов, но 
в каждом есть четыре основные части. 


Во-первых, паттерн проектирования должен иметь однозначное имя. На- 
пример, термин «обертка» («угаррег») в данном случае не годится, пото- 
му что он уже широко распространен и имеет десятки значений. Употреб- 
ление подобного термина в качестве имени паттерна проектирования при- 
ведет только к путанице и неправильному толкованию. 


Поэтому различные техники проектирования, ранее известные под име- 
нем «обертка», сейчас обозначаются именами паттернов Мост (Вт1#е), 
Стратегия (Ѕігаіеву), Фасад (Еасайе), Объектный адаптер (Објесё Адар%- 
ег) и рядом других. Точное имя паттерна имеет явное преимущество пе- 
ред расплывчатым термином, так же как термин «двоичный поиск» на- 
много определеннее и полезнее, чем «поиск». 


Во-вторых, описание паттерна должно определять задачу, на решение ко- 
торой направлен паттерн. Это описание может быть относительно обшир- 
ным или кратким. 


В-третьих, описание паттерна определяет решение задачи. В зависимо- 
сти от ее постановки решение может быть изложено либо на довольно вы- 
соком уровне, либо на относительно низком. Но в любом случае оно долж- 
но быть достаточно общим, чтобы оставалась возможность его настройки 
соответственно различным контекстам, в которых может возникнуть дан- 
ная проблема. 


В-четвертых, описание паттерна определяет и последствия применения 
паттерна к контексту. Как изменится контекст после применения паттер- 
на – в лучшую или в худшую сторону? 


Сделает ли знание паттернов плохого проектировщика хорошим? Здесь 
будет уместна другая аналогия. Вспомним один из тех зубодробительных 
курсов по математике, которые вам, может быть, приходилось изучать 
и сдавать в конце мучительный экзамен, доказывая теоремы. Как пере- 
жить этот кошмар? Очевидный способ состоит в том, чтобы быть гением. 
Начиная с самых основ, вы надстраиваете «здание» всего раздела матема- 
тики и в конце концов доказываете теоремы. Более надежный подход 
предусматривает необходимость запомнить и усвоить много теорем из 
данной области математики, напрячь все отпущенные природой способ- 
ности, призвать на помощь вдохновение и/или удачу, отыскать соответ- 
ствующие вспомогательные теоремы и строить на их основе логические 
цепочки, чтобы доказывать новые теоремы. 
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Такой подход предпочтительнее даже для нашего воображаемого гения, 
поскольку на базе готовых теорем легче строить доказательство и объяс- 
нять его простым смертным. Знание вспомогательных теорем, конечно, 
не гарантирует слабому математику сдачу экзамена, но, по крайней мере, 
позволит ему понять доказательство. 


Так и разработка сложных объектно-ориентированных проектов с нуля 
весьма утомительна. Еще сложнее донести до аудитории смысл оконча- 
тельной конструкции. Роль паттернов проектирования в создании объ- 
ектно-ориентированной конструкции сродни роли, которую в математике 
играют вспомогательные теоремы при доказательстве новой. Паттерны 
проектирования часто описываются как микроархитектуры, которые 
можно сочетать с другими паттернами для создания новой архитектуры. 
Конечно, выбор соответствующих паттернов и эффективное их сочетание 
требуют опыта проектирования и природных способностей. Однако даже 
ваш руководитель сможет понять окончательную конструкцию, если он 
знаком с паттернами. 


Тема 4 | стандартная библиотека шаблонов 


Краткое описание стандартной библиотеки шаблонов (Б$апЧ ага Тетрі1аќіе 
ТАргагу – ТІ.) не может представить всех ее возможностей в проектиро- 
вании. Все нижеизложенное представляет собой лишь затравку, призван- 
ную вдохновить читателя на глубокое изучение ТІ. 


БТІ, не совсем библиотека. Это дарованная свыше идея и набор соглаше- 
ний. 


ТІ, состоит из компонентов трех основных типов: контейнеров, алгорит- 
мов и итераторов. Контейнеры содержат и организуют элементы. Алго- 
ритмы осуществляют операции. Итераторы служат для доступа к элемен- 
там контейнера. Ничего нового, во многих традиционных библиотеках 
эти компоненты есть, и многие традиционные библиотеки реализованы 
с помощью шаблонов. «Божественная» идея ТІ, состоит в том, что кон- 
тейнеры и алгоритмы, работающие с ними, могут и не знать друг о друге. 
Это преимущество достигается с помощью итераторов. 


Итератор имеет сходство с указателем. (По сути, указатели - это одна из 
разновидностей итераторов БТГ..) Как и указатель, итератор может ссы- 
латься на элемент последовательности, может быть разыменован для полу- 
чения значения объекта, на который он ссылается, и может предоставлять 
интерфейс, аналогичный простому указателю для обращения к разным 
элементам последовательности. Итераторы ТІ, могут быть реализованы 
через предопределенные указатели или определяемые пользователями 
типы классов, перегружающие соответствующие операторы, чтобы полу- 
чить синтаксис, аналогичный предопределенному указателю (см. тему 42 
«Умные указатели»). 


Контейнер ТІ, – это абстракция структуры данных, реализованная как 
шаблон класса. Как и структуры данных, разные контейнеры организу- 
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ют свои элементы по-разному для оптимизации доступа или работы с ни- 
ми. ТІ, определяет семь (или, учитывая ѕігіпо, восемь) стандартных 
контейнеров и предлагает еще несколько широко распространенных не- 
стандартных контейнеров. 


Алгоритм ТІ, – это абстракция функции, реализованная как шаблон 
функции (см. тему 60 «Универсальные алгоритмы»). Большинство алго- 
ритмов ТІ, работают с одной или более последовательностями значений, 
где последовательность определяется упорядоченной парой итераторов. 
Первый итератор указывает на первый элемент последовательности, вто- 
рой - на следующий после последнего элемент последовательности (не на 
последний элемент). Если итераторы указывают на одну и ту же ячейку 
памяти, они определяют пустую последовательность. 


Итераторы – это механизм, с помощью которого организуется совместная 
работа контейнеров и алгоритмов. Контейнер может создавать пару ите- 
раторов, обозначающих последовательность его элементов (как всех, так 
и поддиапазона), а алгоритм производит операции с этой последователь- 
ностью. Таким образом, контейнеры и алгоритмы могут тесно сотрудни- 
чать, оставаясь в неведении друг о друге. (Положительный эффект неведе- 
ния в профессиональном программировании на С++ – повторное исполь- 
зование. См. темы 2 «Полиморфизм», 30 «Фабричный метод», 19 «Коман- 
ды и Голливуд» и 60 «Универсальные алгоритмы».) 


Кроме контейнеров, алгоритмов и итераторов, ТІ, определяет ряд вспо- 
могательных возможностей. Алгоритмы и контейнеры могут быть на- 
строены с помощью указателей на функции и объектов-функций (см. те- 
му 20 «Обзекты-функции ТІ»), а эти объекты-функции могут адапти- 
роваться и комбинироваться с помощью различных адаптеров объектов- 
функций. 


Контейнеры также могут быть настроены с помощью адаптеров контейне- 
ров, которые меняют интерфейс контейнера, превращая его в стек, оче- 
редь или очередь с приоритетами. 


В БТІ, широко применяются соглашения. Контейнеры и объекты-функ- 
ции должны описываться через стандартный набор имен вложенных ти- 
пов (см. темы 58 «Встроенная информация о типе», 54 «Свойства» 
и 20 «Обљекты-функции ТІ»). И адаптеры контейнеров, и адаптеры 
объектов-функций требуют от функций-членов наличия определенных 
имен и определенной информации о типе. Алгоритмам необходимо, что- 
бы передаваемые в них итераторы могли поддерживать определенные 
операции и идентифицировать назначение этих операций. Если при ис- 
пользовании и расширении ТІ, соглашение не соблюдается, то рушатся 
и все надежды. Неукоснительное соблюдение соглашений при работе 
с ЭТГ, наоборот, облегчает жизнь разработчика. 
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Соглашения БТГ не определяют деталей реализации, но накладывают 
ограничения эффективности на реализацию. Кроме того, поскольку ТІ, — 
это библиотека шаблонов, большая часть оптимизации и настройки мо- 
жет происходить во время компиляции. Многие упомянутые выше согла- 
шения, касающиеся присваивания имен и включения информации, при- 
няты именно для обеспечения существенной оптимизации времени ком- 
пиляции. Средний специалист, применяющий ТІ, обычно работает так 
же эффективно, как высококвалифицированный специалист, пишущий 
код вручную, и без труда опережает среднего специалиста или любую ко- 
манду программистов, обходящихся без БТГ.. Кроме того, в результате, 
как правило, получается более ясный и легкий в сопровождении код. 


ТІ, надо знать и применять как можно активнее. 


Тема 5 | Ссылки - это псевдонимы, 
а не указатели 


Ссылка – это второе имя объекта. Объект, который инициализировал 
ссылку, может фигурировать в коде как под своим именем, так под име- 
нем ссылки на него. 


іп а = 12 

іпі &га = а; // га - другое имя а 
--га; // а == 11 

а = 10; // га == 10 


іпі *1р = &га; // ір указывает на а 


Ссылки часто путают с указателями, вероятно, потому, что компиляторы 
С++ часто реализуют ссылки как указатели. Однако ссылки – это не ука- 
затели, и ведут они себя по-разному. 


Между ссылками и указателями существуют три основных различия: ну- 
левых ссылок нет, все ссылки требуют инициализации и ссылка всегда 
установлена на объект, которым она инициализирована. В предыдущем 
примере ссылка га будет ссылаться на а в течение всей его жизни. Все са- 
мые грубые ошибки применения ссылок проистекают из непонимания 
этих различий. 


Некоторые компиляторы способны отлавливать явные попытки создания 
нулевой ссылки: 


Етр1оуее &апЕтр1оуее = хѕаїіс_ саѕ<Етр1оуее *>(0); // ошибка! 


Однако компилятор может не выявить менее очевидные попытки созда- 
ния нулевой ссылки, что обусловит неопределенное поведение во время 
выполнения: 
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Етр1оуее хое+АпЕтр10уее(); 


11. 
Етр1оуее &апЕтр1оуее = *«детАпЕтр1оуее(); //вероятно, плохой код 
і?( &апЕтр1оуее ==0 ) //неопределенное поведение 


Если детАпЕтр1оуее возвращает нулевой указатель, поведение этого кода 
неопределенное. В данном случае лучше организовать хранение резуль- 
тата детАпЕтр1оуее при помощи указателя. 


Етр1оуве хетр1оуве = детАпЕтр1оуее(); 
1Е( етр1оуее ) //... 


Требование инициализации ссылки предполагает, что объект, на который 
она установлена, должен существовать на момент инициализации. Это 
важно, поэтому повторю: ссылка представляет собой псевдоним объекта, 
существовавшего до инициализации ссылки. Если ссылка инициализиро- 
вана и установлена на конкретный объект, использовать ее для ссылки на 
другой объект нельзя. Ссылка связана с объектом, инициализировавшим 
ее, в течение всей своей жизни. По сути, после инициализации ссылка ис- 
чезает и далее просто существует еще одно имя инициализировавшего ее 
объекта. Это свойство замещения и является причиной, по которой ссыл- 
ки зачастую удобны в качестве формальных аргументов функции. В сле- 
дующей шаблонной функции ѕмар (перестановка) формальные аргументы 
а ир становятся псевдонимами для фактических аргументов вызова: 


Тетр1афе <+урепате Т> 
уоіа ѕмар( Т ёа, Т ёр ) { 


Т +етр(а); 
а = б; 
р = тетр; 
} 
//. 
іП х= 1, у=2; 
ѕмар( х, у); // х == 2, у == 


В приведенном выше вызове ѕмар а – это псевдоним х,ар – псевдоним у на 
время выполнения вызова. Обратите внимание, что у объекта, на кото- 
рый установлена ссылка, может не быть имени. Таким образом, ссылка 
может применяться для присвоения подходящего имени безымянному 
объекту. 


іп огадеѕ[ МАХ]; 


//... 
ѕмар( дгадез[1], д9гадез[1] ); 


После инициализации формальных аргументов а и 6 шаблона ѕмар для ре- 
альных аргументов дгайеѕ[і] и дгадез[ 1 ] соответственно с этими двумя бе- 
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зымянными элементами массива можно работать посредством псевдонимов 
аир. Это свойство может использоваться для упрощения и оптимизации. 


Рассмотрим следующую функцию, задающую конкретный элемент дву- 
мерного массива: 


іп1іпе №0149 зе{_249( Ғ1оаї *а, іпї т, іпі і, іпі ј ) { 
А = |] = а Р С е че АА зе 11 // ой 


} 


Строку с комментарием «ой!» можно заменить более простым вариантом 
со ссылкой, у которого есть дополнительное преимущество – он правиль- 
ный. (Вы заметили ошибку? Я - только со второго раза.) 


іп1іпе №019 зе{_249( Ғ1оаї ға, ілі т, іпі і, іпі ј ) { 
Ғ1оаі &г = а[і * п + ј]; 
гг жг Ф; 


} 


Ссылку на неконстанту нельзя инициализировать литералом или времен- 
ным значением. 


доиб]е 8а = 12.3; //ошибка! 
змар( $14: :ѕгіпо("Не110”), 314: :ѕїгіпо(", М№ог10")); // ошибки 


А на константу — можно: 


сопзі 90461е &с4 = 12.3; //0К 
Тетр1афе <+урепате Т> 
Т ада( сопѕї Т &а, сопѕї Т 8р ) { 
геїигп а + 0; 
} 
Ия 


сопї 51а: :51гіпо &дгеет1п9д 
= ада(ѕ+а: : ѕёгіпо("Не110"), ѕїа: :ѕїгіпо(", Мог1а")); //0К 


Если ссылка на константу инициализирована литералом, то она указыва- 
ет на временное местоположение, инициализированное литералом. Сле- 
довательно, са фактически ссылается не на литерал 12.3, ана временный 
объект типа йоир1е, который был инициализирован значением 12.3. Ссыл- 
ка дгееїіпод установлена на безымянное возвращаемое значение айі типа 
ѕїгіпд. Обычно временные объекты уничтожаются (т. е. покидают об- 
ласть видимости и для них вызывается деструктор) в конце выражения, 
в котором создаются. Однако когда временный объект используется для 
инициализации ссылки на константу, он существует столько, сколько су- 
ществует ссылка, ссылающаяся на него. 


Тема 6 | Массив как тип формального 
параметра 


С формальными параметрами типа массив связаны некоторые проблемы. 
Главный сюрприз для новичка в С/С++ – отсутствие типа «массив» как 
формального параметра функции, потому что массив передается как ука- 
затель на его первый элемент. 


үоіа ауегаде( іпї агу[12] ); // формальный параметр типа іпі * 
Пуна 
іп апАггау[] = { 1, 2, 3 }; // массив из 3-х элементов 


сопї іпї апАггауЅіхе = 
$17601 (апАггау) /ѕіғео#(апАггау[01); // == 
ауегаде( апАггау ); // допустимо! 


Для автоматического перехода от массива к указателю придуман очаро- 
вательный термин - разложение (4есау). Массив разлагается до указате- 
ля на его первый элемент. Кстати, то же самое происходит и с функция- 
ми. Аргумент функции разлагается до указателя на функцию, но, в отли- 
чие от массива, который теряет свою границу, у разлагающейся функции 
«хватает ума», чтобы сохранять типы своих аргументов и возвращаемый 
тип. (Обратите также внимание на правильное вычисление апАггау517е во 
время компиляции, на которое не влияет изменение набора инициализа- 
торов массива или типа элементов массива.) 


Поскольку граница массива игнорируется в формальном параметре функ- 
ции, то ее, как правило, лучше опустить. Однако если функция ожидает 
в качестве аргумента указатель на последовательность элементов (мас- 
сив), а не указатель на один объект, наверное, лучше поступить так: 


\014 ауегаде( 1п{ агу[] ); // формальный параметр по-прежнему 111 * 
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Если, наоборот, важно точное значение границы массива и требуется, 
чтобы функция принимала только массивы с конкретным числом эле- 
ментов, можно рассмотреть формальный параметр ссылочного типа: 


№014 ауегаде( іп (&агу)[12] ); 


Теперь наша функция будет принимать только массивы целых размером 
12 элементов. 


ауегаде( апАггау ); // ошибка! апАггау размером іпі [3]! 


Шаблоны могут кое-что обобщить: 


Тетр1афе <іпї п> 
\014 ауегаде( іпі (&агу) [п] ); // позволяет компилятору логически вывести п 


но более традиционное решение - явная передача размера массива. 
үоіа амегаде_п( іпі агу[], іпї $17е ); 
Конечно, можно объединить эти два подхода: 


Тетр1афе <іпї п> 
іп1іпе №014 ауегаде( іпї (вагу) [п] ) 
{ ауегаде п( агу, п); } 


Из данного обсуждения должно быть понятно, что одна из основных труд- 
ностей в работе с массивами как с параметрами функций состоит в том, 
что размер массива необходимо задать явно в типе формального парамет- 
ра, передать как отдельный параметр или обозначить символом-ограни- 
чителем в самом массиве (например, '\0’ обозначает конец массива сим- 
волов, образующих строку). Другая сложность в том, что независимо от 
того, как массив объявлен, с ним часто работают посредством указателя 
на его первый элемент. Если этот указатель передается в функцию как 
фактический параметр, то напт предыдущий трюк с объявлением ссылки 
в типе формального параметра не поможет. 


іпі хапАггау2 = пем іп[апАггау$іғе]; 
а 


ауегаде( апАггау2 ); // ошибка! нельзя инициализировать іпі(&) [п] типом іпі = 


ауегаде п( апАггау, апАггау$іхе ); // 0К.. 


Поэтому часто в наиболее традиционных случаях работы с массивами 
лучше применить один из стандартных контейнеров (обычно уесіог или 
ѕігіпо), и, как правило, этот вариант должен рассматриваться в первую 
очередь. (См. также шаблон класса Аггау в теме 61 «Мы создаем экземпляр 
того, что используем».) 
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Объявление многомерных массивов в качестве формальных параметров 
в сущности не намного сложнее, чем объявление простых массивов, но на 
вид страшнее: 


уоіа ргосеѕ5( 1пЕ агу[10][20] ); 


Как и в одномерном случае, формальный параметр – это не массив, а ука- 
затель на первый элемент массива. Однако многомерный массив — это 
массив массивов, поэтому формальный параметр представляет собой ука- 
затель на массив (см. темы 17 «Разбираемся с операторами объявления 
функций и массивов» и 44 «Арифметика указателей»). 


уоіа ргосез$( іпі (агу) [20] ); // указатель на массив, состоящий 
// из 20 элементов типа іп 


Обратите внимание, что вторые (и последующие) границы не разлагают- 
ся, потому что в противном случае было бы невозможно применять ариф- 
метику указателей к формальным параметрам (см. тему 44 «Арифметика 
указателей»). Как уже отмечалось, лучше сообщить человеку, читающе- 
му программу, о том, что фактический параметр должен быть массивом: 


уоіа ргосеѕѕ( іпі агу[ 11201 ); // по-прежнему указатель, но теперь 
// это более очевидно 


Обработка аргументов типа многомерный массив нередко превращается 
в упражнение по низкоуровневому кодированию, когда программист бе- 
рет на себя роль компилятора и занимается вычислением индексов: 


уоіа ргосезз_24( іпі ха, іпі п, іпі п) { // а - это массив п на т 
Ғог( ілі і =0; і < п; ++ ) 
Рог( іп ј = 0; ј <; ++] ) 
ајіхт+ ј] = 0; // индекс вычисляется «вручную» 


} 
И как обычно, иногда можно навести порядок посредством шаблона. 


Тетр1афе <іпї п, іпі т> 
іп1іпе мот ргосеѕ5( іпї (вагу) [11] ) 
{ ргосез$_24( &агу[01[0]1, п, м ); } 


Попросту говоря, формальные параметры типа массив — это сплошная го- 
ловная боль. Поэтому работать с ними надо аккуратно. 


Тема 7 | Константные указатели 
и указатели на константу 


В повседневных разговорах программисты на С++ часто называют указа- 
тели на константу константными указателями. А зря, потому что это два 
совершенно разных понятия. 


Т *рі = пем Т; // указатель на Т 
сопѕі Т *рсї = рі; // указатель на константу Т 
Т *сопзф сре = рї; // константный указатель на Т 


Прежде чем вводить константные квалификаторы в описание указателя, 
необходимо решить, что вы хотите сделать константой: указатель, объ- 
ект, на который он указывает, или и то и другое. В объявлении рсї указа- 
тель не константа, но объект, на который он указывает, считается кон- 
стантой; т. е. константный квалификатор применяется к базовому типу Т, 
а не к модификатору указателя х. В случае с срї объявляется констант- 
ный указатель на объект, не являющийся константой. Константный ква- 
лификатор применяется к модификатору указателя *, а не к базовому ти- 
пу Т. 


Чтобы еще больше запутать синтаксис указателей и констант, определен 
произвольный порядок объявления спецификаторов (т. е. всего того, что 
в описании указателя предшествует первому модификатору +). Так, сле- 
дующие два описания объявляют переменные одного и того же типа: 


СопзЕ Т *р1; // указатель на константу Т 
Т сопз{ *р2; // также указатель на константу Т 


Хотя первая форма более традиционна, многие эксперты С++ сейчас ре- 
комендуют вторую форму на том основании, что она менее неоднозначна. 
Такое описание можно прочитать в обратном направлении, например 
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«указатель на константу Т». В сущности, форму записи можно выбрать 
любую, главное быть последовательным и внимательным, избегая рас- 
пространенной ошибки — путаницы между объявлением константного 
указателя и указателя на константу. 


Т сопзЕ *р3; // указатель на константу 
Т хсопѕї р4 = рї; // константный указатель на неконстанту 


Конечно, можно объявить константный указатель на константу. 


СсопѕЇі Т *сопѕі срсї1 = рї; // все константы 
Т сопзі *сопзф срсї2 = срсЁ1; // то же самое 


Обратите внимание, что часто ссылка предпочтительнее константного 
указателя: 


сопѕі Т &гсї = «рт; // а не сопѕі Т хсопѕі 
Т &гі = *рЕ; // а не Т хсопѕі 


Заметьте, что в некоторых предыдущих примерах можно было преобра- 
зовать указатель на неконстанту в указатель на константу. Например, 
можно было инициализировать рсї (типа сопѕї Т *) значением рї (типа Т +). 
Дело в том, что при этом, попросту говоря, ничего плохого произойти не 
может. Посмотрим, что происходит, когда адрес неконстантного объекта 
копируется в указатель на константу (рис. 7.1). 


Т рї ты Тае 


у 


сопѕї Т *рсі 


Рис. 7.1. Указатель на константу может ссылаться 
на неконстантный объект 


Указатель на константу рсі указывает на неконстантный Т, что не вызы- 
вает никаких проблем. В действительности указатели (или ссылки) на 
константу очень часто ссылаются на неконстантные объекты: 


уоіа аҒипс( сопѕї Т *агд1, сопѕї Т &агд2 ); 
И 

Т ха = пем Т; 

205 

ағипс( а, б ); 
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При вызове аГРипс происходит инициализация агд1 объектом а и агд2 объ- 
ектом р. Мы не утверждаем в связи с этим, что а указывает на констант- 
ный объект или что р представляет собой константу. Мы утверждаем, что 
они будут трактоваться в рамках аГоипс так, как будто являются констан- 
тами, независимо от того, что они собой представляют на самом деле. 
Очень полезная возможность. 


Обратное преобразование — из указателя на константу в указатель на не- 
константу — недопустимо, потому что может быть опасным (рис. 7.2). 


сопѕї Т *рст А сопѕї Т аст 


Рис. 7.2. Указатель на неконстанту не может ссылаться 
на константный объект 


В данном случае рс+ может фактически указывать на объект, определен- 
ный как константный. Если бы можно было преобразовывать указатель 
на константу в указатель на неконстанту, рі мог бы использоваться для 
изменения значения астї. 


сопѕї Т аст; 
рсі = &аст; 
рі = рсі; // ошибка, к счастью 


*рї = аст; // попытка изменить константный объект! 
Стандарт С++ гласит, что такие присваивания приводят к неопределен- 
ным результатам. Что произойдет, точно не известно, но в любом случае 


ничего хорошего ожидать не приходится. Конечно, можно воспользо- 
ваться приведением и провести преобразование явно. 


рі = сопзі саѕ1<Т х>(рсї); // ошибки нет, но не рекомендуется 


рі = ат; // попытка изменить константный объект! 


Однако поведение операции присваивания остается неопределенным, ес- 
ли рї указывает на объект, который, как и аст, объявлен константным 
(см. тему 9 «Новые операторы приведения»). 


Тема 8 | Указатели на указатели 


Можно объявить указатель на указатель. В стандарте С++ такой указа- 
тель называется многоуровневым. 


іп *р1; // указатель 
іп **ррі; // двухуровневый указатель 
іп ***рррі; // трехуровневый указатель 


Хотя указатели с уровнем больше двух встречаются редко, есть два рас- 
пространенных случая применения указателей на указатели. Первый — 
когда объявляется массив указателей. 


Ѕһаре *расфиге[ МАХ]; // массив указателей на Ѕһаре 


Поскольку имя массива разлагается в указатель на его первый элемент 
(см. тему 6 «Массив как тип формального параметра»), имя массива 
указателей также представляет собой указатель на указатель. 


Ѕһаре **ріс1 = расфиге; 


Чаще всего такое применение можно увидеть в реализации класса, управ- 
ляющего буфером указателей: 


Тетр1афе <+урепате Т> 
с1аѕѕ Рігүесїог { 
рир1іс: 
ехр1ісії РЕг\есфог( ѕіхе ї сарасі+у ) 
: ри? (пем Т *[сарасі?у]), сар (сарасіїу), ѕіхе (0) {} 
аа 


ргімаїе: 
Т х*ри?; // указатель на массив указателей на Т 
5176 і сар_; // емкость 


Ѕі7е і ѕіғе ; // размер 
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}; 
е 
РігМесіог<Ѕһаре> ріс2( МАХ ); 


Как подсказывает реализация Ріг\есїог, указатели на указатели могут 
быть сложными. Лучше, чтобы они были скрытыми. 


Изменение функцией значения переданного в нее указателя — второй об- 
щий случай использования многоуровневых указателей. Рассмотрим 
следующую функцию, которая меняет указатель так, чтобы он ссылался 
на следующий случай употребления символа в строке: 


уоіа зсапТо( сопѕі сһаг **р, сһаг с ) { 
мһі1е( **р && **р = с) 
++*р; 


} 


Первый аргумент зсапТо – указатель, значение которого мы хотим изме- 
нить. Это означает необходимость передачи адреса указателя: 


сһаг 3[] = "Не110, Мог1а!"; 
сопѕї сһаг *ср = $; 
ѕсапТо( &ср, ',’); // перемещает ср на первую запятую 


Такое применение рационально в С. Однако в С++ проще, безопаснее 
и привычнее использовать как аргумент функции не указатель на указа- 
тель, ассылку на указатель. 


уоіа зсапТо( сопѕі сһаг *&р, сһаг с ) { 
м011е( *р && *р != с) 
++р; 


} 


И 
сһаг 3[] = "Не110, Мог1а!"; 


сопѕї сһаг *ср = $; 
зсапТо( ср, ',’); 


В С++ практически всегда в функции ссылку на указатель следует пред- 
почесть указателю на указатель. 


Широко распространено следующее заблуждение: преобразования, при- 
меняемые к указателям, также применимы и к указателям на указатели. 
Это не так. К, примеру, известно, что указатель на производный класс мо- 
жет быть преобразован в указатель на его открытый базовый класс: 


Сігс1е *с = пем Сігс1е; 
Ѕһаре *$ = с; // замечательно... 
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Поскольку Сігс1е (Круг) является объектом Ѕһаре (Фигура), указатель на 
Сігс1е также является указателем на Ѕһаре. Однако указатель на указа- 
тель на Сігс1е не является указателем на указатель на 5паре: 


Сігс1е **сс = &С; 
Ѕһаре **5$ = сс; // ошибка! 


Такая же путаница часто возникает при работе с константами. Известно, 
что допускается преобразование указателя на неконстанту в указатель на 
константу (см. тему 7 «Константные указатели и указатели на кон- 
станту»), но нельзя преобразовать указатель на указатель на неконстан- 
ту в указатель на указатель на константу: 


сһаг *$1 = 0; 

сопѕї сһаг *52 = $1; // ОК... 

сһаг ха[ МАХ]; // также можно записать спаг ** 
сопѕї сһаг **рз = а; // ошибка! 


Тема 9 | Новые операторы приведения 


Приведение в старом стиле штука отчасти скрытная и коварная. Синтак- 
сис этих операторов приведения таков, что нередко они остаются незаме- 
ченными в программном коде и могут приводить к большим неприятно- 
стям. Давайте определимся, что имеется в виду под «приведением в ста- 
ром стиле». Очевидно, что оригинальный синтаксис С, согласно которому 
заключенный в скобки тип применяется к выражению, и есть приведение 
в старом стиле: 


сһаг *ПореТЕмогк$ = (сһаг *)0х00170000; // приведение в старом стиле 


В С++ принят другой способ записи. В нем то же самое можно предста- 
вить с помощью синтаксиса функционального стиля приведения: 


уреде? спаг *РСпаг; 
пореГ{Могк$ = 
РСпаг( 0х00ғ#0000 ); // функциональный/старый стиль приведения 


Функциональный стиль приведения, может быть, выглядит приличнее, 
чем его ужасный предшественник, но он настолько же отвратителен. От 
них обоих надо бежать, как от чумы. 


Настоящие программисты предпочитают новые операторы приведения, 
которые позволяют более строго оформлять в виде кода свои мысли и точ- 
нее формулировать сами мысли. Этих операторов всего четыре, и у каж- 
дого из них свое специальное назначение. 


Оператор сопѕї_саѕї позволяет добавлять или удалять квалификаторы ти- 
пов сопѕї и уо1аїі1е из типа выражения: 


сопѕї Регѕоп *де+Етр1оуее() { ... } 


//... 
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Регзоп *апЕтр1оуее = сопѕі саѕі<Регѕоп *>(деЕЕтр1оуее()); 


В этом коде сопзі саѕї позволяет аннулировать квалификатор типа сопѕї 
в возвращаемом типе де+Етр1оуее. Такой же результат можно было бы по- 
лучить, применив приведение в старом стиле: 


апЕтр1оуее = (Регзоп *)детЕтр1оуее(); 


но сопз{_саз{ лучше по нескольким причинам. Во-первых, он очевиден 
и отвратителен. Он торчит в коде, как бревно в глазу, и это хорошо, потому 
что приведения опасны в любой форме. Писать их должно быть мучением, 
потому что их следует применять только в случае необходимости. Их 
должно быть легко найти, потому что приведения - это то, что проверяет- 
ся в первую очередь при возникновении ошибок. Во-вторых, сопз{_саз+{ об- 
ладает меньшей силой, чем приведение в старом стиле, поскольку влияет 
только на квалификаторы типов. Это ограничение тоже имеет положи- 
тельный эффект, потому что обеспечивает возможность точнее обозначить 
намерения. Применение приведения в старом стиле заставляет компиля- 
тор замолчать, потому что вы хотите, чтобы возвращаемым типом деіЕтр- 
1оуее был Регѕоп *. Применение сопѕї саѕї заставляет компилятор замол- 
чать, потому что вы хотите убрать сопѕї из возвращаемого типа детЕтр- 
1оуее. Разница между этими двумя выражениями не так уж и велика (их 
даже объединяет их отвратительность), пока кто-нибудь не захочет изме- 
нить функцию деїЕтр1оуее: 


сопзі Етр1оуее *«детЕтр1оуее(); // значительное изменение! 


«Правило кляпа», навязанное приведением в старом стиле, по-прежнему 
действует. Компилятор не просигнализирует о неверном преобразовании 
сопзі Етр1оуее * в Регѕоп *, но пожалуется, если такое случится при исполь- 
зовании сопѕї саѕі, потому что столь радикальное изменение выходит за 
рамки его возможностей. Короче говоря, сопѕї саѕї предпочтительнее 
приведения в старом стиле, потому что сопѕї_саѕї еще более уродлив, его 
сложнее использовать и у него меньше возможностей. 


Оператор ѕїаїіс_саѕї применяется для переносимых на разные платфор- 
мы приведений. Чаще всего он служит для приведения «вниз» по иерар- 
хии наследования от указателя или ссылки на базовый класс к указателю 
или ссылке на производный класс (см. также тему 27 «Запросы возмож- 
ностей»): 


Ѕһаре *зр = пем С1гс1е; 
Сігс1е *ср = зїаїіс саѕї<Сігс1ө *>(5р); // нисходящее приведение 


В данном случае ѕіаїіс саѕї обеспечивает безошибочную компиляцию, по- 
тому что 5р действительно ссылается на объект Сігс1е. Однако если бы зр 
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указывал на какой-нибудь другой тип Ѕһаре, при использовании ср мы, ско- 
рее всего, получили бы ошибку времени выполнения. Повторяю, эти новые 
операторы приведения безопаснее, чем старые, но не всегда безопасны. 


Обратите внимание, что $1а{1с_саз{ не должен изменять квалификаторы 
типа так, как это может сопѕї_саѕї!. Это означает, что порой необходимо 
использовать последовательность двух новых операторов приведения, 
чтобы достичь результата, обеспечиваемого приведением в старом стиле: 


сопзі Ѕһаре *ое+ћехі$һаре() {... } 
е 
Сігс1е *ср = 


ѕіаііс_саѕї<Сігс1е *>(сопѕі саѕї<Ѕ$һаре *>(деїМ№ехїЅһаре())); 


Стандарт не гарантирует поведения оператора геіпіегргеї_саѕї, но, как 
правило, оно соответствует его имени: он работает с битами объекта и по- 
зволяет осуществлять преобразования между совершенно несвязанными 
типами: 


һореІМогКкѕ = // преобразуем целое в указатель 
геіпіегргеї_саѕі<сһаг *>(0х00110000); 
іпї *Поре1ез$ = // преобразуем спаг * в іпї * 


геіпіегргеї_саѕзі<іпі *>(поретМогк$); 


Подобные вещи иногда приходится делать в коде низкого уровня, но та- 
кое преобразование не является переносимым. Применять его следует 
с осторожностью. Обратите внимание на разницу между геіпіегргеї_саѕі 
и ѕіаїіс_саѕї при нисходящем приведении от указателя на базовый класс 
к указателю на производный класс. Оператор геіпїегргеї_саѕї обычно 
считает, что указатель на базовый класс является указателем на произ- 
водный класс, и не меняет его значение, тогда как ѕіаїііс саѕї (и приведе- 
ние в старом стиле, если на то пошло) осуществляет правильную работу 
с адресами (см. тему 28 «Смысл сравнения указателей»). 


Разговор о приведении в рамках иерархии приводит нас к оператору дупа- 
піс_саѕї. Он обычно применяется для безопасного нисходящего приведе- 
ния от указателя на базовый класс к указателю на производный класс 
(см., однако, тему 27 «Запросы возможностей»). От ѕїаїіс_саѕї оператор 
дупапіс_саѕї отличается тем, что нисходящее приведение может осуществ- 
ляться только для полиморфного типа (т. е. тип приводимого выражения 
должен быть указателем на тип класса с виртуальной функцией) и пра- 
вильность приведения проверяется во время выполнения. Однако безопас- 


1 Стандарт языка С++ позволяет добавлять квалификаторы сопѕї и \01а111е с по- 
мощью оператора ѕїаїіс саѕї, однако удаление указанных квалификаторов 
с помощью ѕіаїіс саѕї запрещается (см., например, [ЗО ІЕС 14882 п. 5.2.9). 
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ность не бесплатна. У оператора ѕїаїіс_саѕї издержки обычно отсутству- 
ют или минимальны, тогда как дупат1с_сазф предполагает существенные 
издержки времени выполнения. 


сопѕї С1гс1е *ср = 
дупатіс_саѕі<сопѕїі Сігс16 *>( деїМехїЅһаре() ); 
РС ер) {е } 


Если деїћехіЅ$һаре возвращает указатель на Сігс1е (или какой-то наследуе- 
мый открыто от Сігс1е класс, т.е. нечто, являющееся (ігс1е; см. тему 2 
«Полиморфизм»), приведение будет успешным и ср будет указывать на 
Сігс1е. В противном случае ср будет нулевым. Обратите внимание, что 
объявление и тестирование можно комбинировать в одном выражении: 


ТЕ сопзЕ Сігс1е *ср 
= йупатіс саѕі<сопѕї Сігс1е х>(деїМехіЅһаре()) ) {...} 


Это выгодно, потому что тем самым область видимости переменной ср ог- 
раничивается выражением ії. Таким образом, ср, когда в ней исчезнет 
необходимость, просто уйдет из области видимости. 


Несколько реже йупапіс_саѕї применяется для нисходящего приведения 
к ссылочному типу: 


сопзі Сігс16 &гс = дупатіс саѕі<сопѕі Сігс1е &>(«деіМехіѕһаре()); 


Операция аналогична приведению указателя с помощью йупапіс_саѕї, но 
если приведение не удается, оператор формирует исключение типа 
ѕїа: :раа_саѕї вместо возврата нулевого указателя. (Вспомните, что нуле- 
вых ссылок нет; см. тему 5 «Ссылки – это псевдонимы, а не указатели» .) 
Можно сказать, что применение дупат1с_саз+ к указателю — это вопрос 
(«Этот указатель на Ѕһаре фактически указывает на Сігс1е? Если нет, я мо- 
гу заняться этим.»), тогда как применение дупат1с_саз1 к ссылке является 
утверждением («Предполагается, что этот 5Паре есть не что иное, как Сіг- 
с1е. Если это не так, значит, что-то не в порядке!» ). 


Как и со всеми остальными новыми операторами приведения, необходи- 
мость в йупапіс_саѕї возникает лишь время от времени. Но из-за репута- 
ции «безопасного» приведения им часто злоупотребляют. Пример такого 
злоупотребления можно найти в теме 30 «Фабричный метод». 


Тема 10 | Смысл константной 
функции-члена 


С технической точки зрения константные функции-члены тривиальны. 
Однако их взаимоотношения с окружением могут быть сложными. 


Типом указателя {11$ в неконстантной функции-члене класса Х является 
Х *сопѕї. Другими словами, это константный указатель на неконстантный 
Х (см. тему 7 «Константные указатели и указатели на константу»). 
Поскольку объект, на который ссылается 111$, неконстантный, он может 
быть изменен. Типом {11$ в константной функции-члене класса Х являет- 
ся сопѕї Х *сопѕі — константный указатель на константный Х. Поскольку 
объект, на который ссылается 111$, константный, он не может быть изме- 
нен. В этом разница между константными и неконстантными функция- 
ми-членами. 


Вот почему можно изменять логическое состояние объекта с помощью 
константной функции-члена, даже если физическое состояние объекта 
остается неизменным. Рассмотрим следующую банальную реализацию 
класса Х, в котором фигурирует указатель на буфер, выделенный для хра- 
нения некоторой части его состояния: 


с1а55 Х { 
рир11с: 
Х() : биғ#ғег_ (0), іѕСотри+еа (Ға15е) {} 
ет 
уоіа ѕеїВи#ғег() { 
іп тр = пем іпЕ[МАХ]; 
де1еїе [] би#ғег _; 
ри?ғег_ = їтр 
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уоіа мод1РуВиЕРег( іпі іпаех, іпї уа1ие ) сопзЕ // противоречит нормам 


{ бигГег_[1пдех] = уа1ие; } 
іпї дет\а1ие() сопѕї { 
1?( !1$Сотритед_ ) { 
сотри+едуа1џе_ = ехрепѕіуедрегатіоп(); // ошибка! 
іѕСотри+еа_ = гие; // ошибка! 


} 
геъигп сотрифед\/а1ие_; 


} 
рг1\ате: 

ѕ+аііс іпі ехрепѕіуе0регаїіоп(); 

іпі *риғғег_; 

6001 іѕСотри+еа ; 

іпі сотри+еа\а1џе _; 


}; 


Функция-член ѕеїВи?ѓег должна быть неконстантной, потому что меняет 
поля своего объекта Х. Однако тод1ТуВи!Тег вполне может быть констант- 
ной, потому что меняет не объект Х, а лишь некоторые данные, на кото- 
рые ссылается его поле ри! Тег_тетрег. 


Это законно, но так поступать нельзя. Как недобросовестный адвокат, 
следующий букве закона, но при этом нарушающий его суть, програм- 
мист на С++, пишущий константную функцию-член, которая изменяет 
логическое состояние своего объекта, будет как минимум осужден свои- 
ми коллегами (если не компилятором). Это просто неправильно. 


Наоборот, иногда функция-член, фактически объявленная константной, 
должна менять свой объект. Это обычная ситуация при нахождении зна- 
чения путем «отложенного вычисления», когда для повышения произво- 
дительности значение не вычисляется до первого запроса. В функции 
Х: : де \/а1ие делается попытка осуществить отложенное вычисление ре- 
сурсоемкого выражения. Но поскольку оно объявлено как константная 
функция-член, Х: : де1\/а1ие не может задавать значения атрибутов 1$Соп- 
риіеа_ и сотритед\а1ие_ своего объекта Х. В подобных ситуациях есть со- 
блазн переступить закон и провести приведение, чтобы получить выгоду 
от возможности объявить функцию-член константной: 


іпі дет\а1ие() сопѕї { 
1Р( 1 іѕСотриеа_ ) { 
Х *сопѕї атһіѕ = сопѕї_саѕї<Х *сопѕї>(+һіѕ); // плохая идея! 
атћіѕ->сотриїеа\а1џе_ = ехрепѕіуе0рега+іоп(); 
атһћіѕ->1ѕСотритей_ = гие; 
} 
гефигпт сотритед\/а1ие_; 
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Не поддавайтесь искушению. Чтобы справиться с этой ситуацией, надо 
объявить соответствующие данные-члены с модификатором пиїар1е: 


с1аѕ5 Х { 
рир1іс: 
Ў 
іп дет\а1ие() сопѕ+ { 
ТЕ !іѕСотриеа_ ) { 
сотрифед\/а]1ие_ = ехрепѕіуе0рега+іоп(); // все в порядке. . 
іѕСотриїтеа_ = гие; // тоже все в порядке. . 
} 
гефигп сотрифед\/а1ие_; 
} 


рг1\ате: 
И 
тифаб]е 6001 іѕСотри+еа ; // теперь может быть изменен 
ти+аб1е іпї сотритед\а1ие_; // теперь может быть изменен 


}; 


Нестатические данные-члены класса могут быть объявлены с модифика- 
тором пита Те, что позволит изменять их значения константным функци- 
ям-членам класса (как и неконстантным функциям-членам). Это в свою 
очередь обеспечивает возможность объявлять константной «логически 
константную» функцию-член, даже несмотря на то, что реализация тре- 
бует изменения ее объекта. 


Влиянием константности на тип указателя 115 функции-члена также 
объясняется то, как разрешение перегрузки функции может различать 
константные и неконстантные версии функции-члена. Рассмотрим сле- 
дующий вездесущий пример перегруженного индексного оператора: 


с1а55 Х { 
рир11с: 
е 
іпї &орега+ог [](іпї іпаех) 
СсопѕЇі іпїі &орегаїог [](іпі іпаех) сопѕ+; 
Иры 
}; 


Вспомним, что левый аргумент бинарного перегруженного оператора- 
члена передается как указатель 111$. Следовательно, при индексации объ- 
екта Х его адрес передается как указатель 1115: 


іп і = 12 

Ха; 

а[7] = і; // это Х *сопѕї, потому что а не константа 
сопѕї Хр 


і = 01]; // это сопѕї Х *сопѕї, потому что р константа 
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Разрешение перегрузки сопоставит адрес константного объекта с указа- 
телем 111$, который указывает на константу. В качестве другого примера 
рассмотрим следующий бинарный оператор-нечлен с двумя константны- 
ми аргументами: 


Х орегафог +( сопѕі Х &, сопз+ Х & ); 


Если понадобится объявить функцию-член, аналогичную этому перегру- 
женному оператору, для сохранения константности левого аргумента он 
должен быть объявлен константной функцией-членом: 


с1аѕ5 Х { 
рир1іс: 
СЕ 


Х орегатог +( сопзЕ Х &гідһЕАго ); // левый аргумент не константа! 


Х орегафог +( сопѕї Х &гідһіАго ) сопзі; // левый аргумент - константа 
Я в 
}; 


Правильное программирование на С++ с применением констант не отли- 
чается технической сложностью, но подвергает испытанию дух програм- 
миста, в чем просматривается аналогия с повседневной жизнью. 


Тема 11 | Компилятор дополняет классы 


Программисты на С привыкли знать все о внутреннем устройстве и ком- 
поновке структур и писать код, зависящий от определенной компоновки. 
Јауа-программисты привыкли программировать, не зная о компоновке 
структуры своих объектов, и иногда думают, что при переходе на С++ 
эпоха неведения заканчивается. Однако написание безопасного и перено- 
симого кода на С++ требует частичного признания непознаваемости 
структуры и компоновки объектов класса. 


Для класса не всегда действует правило «что вижу, то и имею». Напри- 
мер, большинство программистов на С++ знают, что если класс объявля- 
ет одну или более виртуальных функций, компилятор вставит в каждый 
объект этого класса указатель на таблицу виртуальных функций. (На са- 
мом деле это не гарантируется стандартом, но все существующие компи- 
ляторы С++ реализуют виртуальные функции именно так.) Однако про- 
граммисты на С++, находясь на этой опасной грани между знанием 
и опытом, часто пишут код исходя из предположения, что положение 
указателя таблицы виртуальных функций остается неизменным от плат- 
формы к платформе. Это грубейшая ошибка! Одни компиляторы помеща- 
ют указатель в начале объекта, другие – в конце, а если задействовано 
множественное наследование, по объекту может быть разбросано не- 
сколько указателей таблицы виртуальных функций. Какие-либо предпо- 
ложения недопустимы. 


И это еще не все. При виртуальном наследовании объекты могут отслежи- 
вать местоположение своих виртуальных подобъектов базового класса 
с помощью встроенных указателей, встроенных смещений или невстроен- 
ной информации. Указатель таблицы виртуальных функций может по- 
явиться, даже если в классе нет виртуальных функций! Разве я не гово- 
рил, что компилятор также может переупорядочивать члены данных не- 
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сколькими способами независимо от порядка, в котором они были объяв- 
лены? Настанет ли конец этому безумию? 


Настанет. Для того чтобы получить класс, гарантированно аналогичный 
С-структуре, можно определить РОР (р]аш о! даѓа – простые данные 
в стиле С). Конечно, к РОР” относятся не только встроенные типы, такие 
как 111, 904 ]е и аналогичные, но и типы, объявленные в С, подобные 
эТгист или ипіоп. 


ѕігисї $ { // РОб-структура 
іпї а; 
доир1е б; 

}; 


Работа с такими РОР-структурами так же безопасна, как с соответствую- 
щими конструкциями С (степень этой безопасности в С++ не вызывает со- 
мнений настолько же, как ив С). Однако если РОР-структуры планируется 
задействовать в программном коде низкого уровня, то они должны и с точ- 
ки зрения обработки их компилятором оставаться данными в стиле С, 
иначе все пропало: 


ѕігисі 9 { // больше не РО0-структура! 
іпї а; 
доир1е б; 
ргімаїе: 
ѕіа::ѕігіпо с; // выполняется некоторая обработка компилятором, 
// не характерная для РОО 
}; 


Но какое значение имеет это вмешательство компилятора для последую- 
щей работы с объектами класса, если разработчик не желает иметь дело 
только с РО? Оно означает, что работать с объектами класса можно 
только на высоком уровне, а не как с наборами битов. Высокоуровневая 
операция от платформы к платформе может делать «одно и то же», но вы- 
полняться будет по-разному. 


Например, если необходимо скопировать объект класса, никогда нельзя 
использовать блочное копирование, обеспечиваемое стандартной функ- 
цией пепсру или самостоятельно разработанным ее эквивалентом. Они 
предназначены для копирования хранилищ, но не объектов (это отличие 
обсуждается в теме 35 «Синтаксис размещения пеш»). Необходимо ис- 
пользовать реализуемые объектом операции инициализации или присва- 
ивания. Конструктор объекта — это то место, где компилятор вызывает 
скрытый механизм, реализующий виртуальные функции объекта и т. п. 
Простое внедрение набора битов в неинициализированное хранилище мо- 
жет не привести к желаемому результату. Аналогично при копировании 
одного объекта в другой необходимо позаботиться о том, чтобы при этом 
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не произошла перезапись механизмов этого класса. Например, присваи- 
вание никогда не меняет значения указателей таблицы виртуальных 
функций объекта. Они задаются конструктором и не меняются в течение 
жизни объекта. Внедрение битов может разрушить эту нежную внутрен- 
нюю структуру. (См. также тему 13 «Операции копирования».) 


Другая широко распространенная проблема связана с предположением 
о неизменном соответствии определенного члена класса заданному сме- 
щению в рамках объекта. Скажем, в каком-нибудь заумном коде нередко 
принимают, что нулевому смещению соответствует или указатель на таб- 
лицу виртуальных функций, или поле, являющееся первым в объявлении 
класса. Оба предположения правильны не более чем наполовину, и конеч- 
но же, они не могут быть истинными одновременно. 


ѕігисі Т { // не РОБ 
11 а; // смещение а_ неизвестно 
уігіџа1 моіа #(); // смещение уріг неизвестно 
| 


Я не собираюсь развивать данную тему, потому что этот список окажется 
довольно длинным, скучным и, наверное, неинтересным. Но в следую- 
щий раз, когда вы будете делать предположения о внутренней структуре 
своих классов, остановитесь, подумайте и избавьтесь от предрассудков! 


Тема 12 | Присваивание и инициализация - 
это не одно и то же 


Инициализация и присваивание – это разные операции, которые приме- 
няются и реализуются по-разному. 


Давайте разложим все по полочкам. Присваивание имеет место, когда 
что-то присваивается. Все остальные операции копирования — это ини- 
циализация, включая инициализацию при объявлении, возвращении 
значения функцией, передаче аргумента и перехвате исключений. 


Присваивание и инициализация – абсолютно разные операции не только 
потому, что используются в разных контекстах, но и потому, что выпол- 
няют абсолютно разные действия. Эта разница не столь очевидна для 
встроенных типов, таких как 111 или 4ои01е, поскольку в их случае и при- 
сваивание, и инициализация состоят в простом копировании битов (но 
см. также тему 5 «Ссылки — это псевдонимы, а не указатели»): 


іп а = 12; // инициализация, копирование 0Х000С в а 
а = 12; // присваивание, копирование 0Х000С в а 


Однако для пользовательских типов ситуация может быть совершенно 
другой. Рассмотрим следующий простой нестандартный класс для рабо- 
ты со строками: 


с1а55 Ѕігіпд { 
рир11с: 

Ѕігіпо( сопѕї сһаг *іпії ); // намеренно без ключевого слова «ехріісії» 
75+гіпо(); 
Ѕгіпо( сопѕі 5ігіпо &ЕваЕ ); 
бігіпод &орегафог =( сопѕї Ѕїгіпо &+ћһа+ ); 
Ѕігіпо &орегаїог =( сопзЕ сһаг *ѕ+г ); 
үоіа змар( 51гіпо &іһа+ ); 
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Ғгіепа сопѕї 5г1п9 // конкатенация 
орегатог +( сопзф Ѕігіпо &, сопѕї Ѕїгіпо & ); 
Ғгіепа 6001 орега+ог <( сопзі Ѕігіпо &, сопѕі 51г1пд & ) 
ч 
ргімаїе: 
Ѕігіпо( сопѕї сһаг *, сопзЕ сһаг * ); // вычислительный 
сһаг *5_; 


}; 


Инициализация объекта строкой символов проста. Выделяется буфер, 
достаточно большой для размещения копии строки символов, и затем 
происходит копирование. 


гіпо: :5г119( сопѕї сһаг хіпі ) { 
1Р( !іпі ) іпії = ""; 
$_ = пем сһаг[ ѕэїг1еп(іпії)+1 ]; 
ѕігсру( $_, іпії ); 

} 


Деструктор делает то, что должен делать: 
$г1п9: :-57119() { Чдетете [] 5; } 
Присваивание – несколько более сложная задача, чем создание: 


гіпо &51гіпд::орега+ог =( сопѕї сһаг *ѕїг ) { 
ТЕ !ѕіг ) ѕіг = ""; 
сһаг *їтр = ѕігсру( пем сваг[ ѕэїг1еп(ѕїіг)+1 ], ѕїг ); 
де1ете [] $; 
$_ = р; 
гефигп *{01$ 


} 


Присваивание похоже на уничтожение с последующим созданием. Для 
составных пользовательских типов цель (левая половина или 1115) долж- 
на быть очищена перед повторной инициализацией источником (правая 
половина или ѕїг). В нашем случае с типом 5їгіпо его существующий бу- 
фер должен быть высвобожден перед прикреплением нового буфера сим- 
волов. В теме 39 «Надежные функции» объясняется порядок инструк- 
ций. (Между прочим, практически каждую неделю кому-нибудь да при- 
ходит в голову светлая мысль реализовать присваивание, явно вызывая 
деструктор, а для вызова конструктора прибегая к ключевому слову пем. 
Это не всегда работает и небезопасно. Не делайте так.) 


Корректная операция присваивания очищает левый аргумент, поэтому 
не допускается пользовательское присваивание для неинициализирован- 
ного хранилища: 


$1г1п9 *патеѕ = ѕіаіс саѕі<5їгіпо *>(::орегафог пем( ВУЕЗТЯ )); 
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патез[0] = "Закамофо”; // ой! применение де1еїе [1] 
// к неинициализированному указателю! 


В данном случае патез (имена) ссылается на неинициализированное хра- 
нилище, потому что орегаїог пем вызван напрямую, что исключает неяв- 
ную инициализацию стандартным конструктором 51г1п19. Переменная 
патез ссылается на область памяти, заполненную случайными битами. Ко- 
гда во второй строке будет вызван оператор присваивания 51/119, он попы- 
тается удалить массив по неинициализированному указателю. (Безопас- 
ный способ осуществления операции, подобной такому присваиванию, 
приведен в теме 35 «Синтаксис размещения пеи».) 


У конструктора меньше работы, чем у оператора присваивания (т. к. кон- 
структор предполагает, что хранилище неинициализировано), поэтому 
реализация для повышения эффективности иногда основывается на так 
называемом вычислительном конструкторе (сотрилаНопа] сопѕігисіог): 


сопѕЇ Ѕігіпо орегафог +( сопѕї Ѕїгіпо &а, сопѕї Ѕігіпо &6 ) 
{ гетигп Ѕгіпо( а.з_, 0.5 ); } 


Двухаргументный вычислительный конструктор не рассматривается как 
часть интерфейса класса 51г1п9, поэтому объявляется закрытым. 


гіпо: :51гіпо( сопѕї сһаг ха, сопѕї сһаг *р ) { 
5_ = пем спаг[ ѕігіеп(а)+ѕ+г1еп(0)+1 ]; 
ѕігсаї( ѕїгсру( з_, а), р ); 


Тема 13 | Операции копирования 


Копирующее создание и копирующее присваивание – это разные опера- 
ции. С технической точки зренияу них нет ничего общего, но они близки 
друг другу «социально» и должны быть совместимыми. 


с1а55 Ітр1 
с1аѕѕ Напа1е { 
рир11с: 
Из 
Напд1е( сопѕі Напа1е & ); // копирующий конструктор 
Напа1е ворегафог =( сопзі Напд1е & ); // копирующее присваивание 
уоіа змар( Напа1е & ); 
Ин 
ргіуаї+е: 
Ітр1 *1тр1_; // указатель на реализацию Напа1е 


}; 


Копирование встречается настолько часто, что соблюдать соглашения 
при его осуществлении еще важнее, чем обычно. Эти операции всегда объ- 
являются попарно соответственно приведенной выше сигнатуре (см., од- 
нако, темы 48 «Указатель аиїіо ріг – штука странная» и 32 «Предот- 
вращение копирования»). То есть для класса Х копирующий конструктор 
должен быть объявлен как Х(сопѕї Х &), а оператор копирующего присва- 
ивания – как Х &0регаїог =(сопѕї Х &). Как правило, целесообразно, и широ- 
ко применяется определение функции-члена ѕмар в том случае, если реа- 
лизация змар как функции-члена дает преимущество в производительно- 
сти или безопасности, по сравнению с традиционной ѕмар (нечленом). Реа- 
лизация обычной ѕмар, не являющейся членом, проста: 


Тетр1афе <+урепате Т> 
уоіа ѕмар( Т 8а, Т 86 ) { 
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+етр(а); // копирующий конструктор Т 
= 0; // копирующее присваивание Т 
р = тетр; // копирующее присваивание Т 


о ч 


} 


Эта функция ѕмар (идентичная ѕмар стандартной библиотеки) определяет- 
ся на основании операций копирования типа Т и хороша, если реализация 
Т небольшая и простая. В противном случае она может приводить к на- 
кладным расходам. Для класса, подобного Нап ]е, есть вариант получше: 
просто поменять местами указатели на его реализацию. 


іп1іпе моіа Напа1е: : ѕмар( Напа1е &їћа+ ) 
{ 5а: :ѕмар( 1тр1_, +һаї. 1тр1_ ); } 


Помните комедийный номер, в котором рассказывалось, как получить 
миллион долларов и не платить с них налоги? Во-первых, получаем мил- 
лион долларов... Точно так же можно показать, как написать безопасную 
операцию копирующего присваивания. Сначала получаем безопасный ко- 
пирующий конструктор и безопасную операцию ѕмар. Остальное просто: 


Напа1е &Напа]е: :орегафог =( сопѕі Напа1е &їћаі ) { 
Напа1е +етр( +һаї ); // безопасное копирующее создание 
ѕмар( +етр ); // безопасная ѕмар 
геигп *1һіѕ; // предполагаем, что уничтожение +етр 
// не сформирует исключения 


} 


Эта техника особенно хороша для классов-«дескрипторов», т.е. классов, 
состоящих преимущественно или полностью из указателей на их реали- 
зации. Как мы видели в предыдущем примере, создание безопасных опе- 
раций змар для таких классов не отличается сложностью и дает большой 


эффект. 


Тонкость этой реализации копирующего присваивания в том, что его по- 
ведение и поведение копирующего создания должны быть совместимыми. 
Это разные операции, однако заведомо предполагается, что их результа- 
ты будут неотличимы. То есть если записано 


Напа1е а =... 
Напа1е 0; 
р = а; // присваиваем акр 


или 


Напаіе а =... 
Напа1е 0( а ); // инициализируем 0 значением а 


получаемое в результате значение и будущее поведение 6 должны быть 
идентичны независимо от того, как именно это значение получено – по- 
средством присваивания или инициализации. 
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Такая совместимость исключительно важна при использовании стан- 
дартных контейнеров, потому что их реализации часто подменяют копи- 
рующее создание копирующим присваиванием, предполагая, что эти 
операции обеспечивают идентичные результаты (см. тему 35 «Синтак- 
сис размещения пеш»). 


Вот еще одна, наверное, более распространенная реализация копирующе- 
го присваивания: 


Напа1е &Напа]е: :орегафог =( сопѕі Напа1е &їћаі ) { 
1Р( 101$ |= &їһаї ) { 
// осуществляется присваивание. . . 


} 
гефигп *{01$; 


} 


Часто с целью обеспечения правильности необходимо, а иногда это и бо- 
лее эффективно, выполнить проверку на наличие самоприсваивания, 
т.е. убедиться, что адреса левой (111$) и правой (їһаї) частей присваива- 
ния разные. 


Большинство программистов С++ хотя бы раз в течение карьеры экспе- 
риментируют с идеей реализации виртуального копирующего присваива- 
ния. Ничего незаконного в ней нет, но она несколько запутанна, и лучше 
оставить ее в покое. То ли дело клонирование (см. тему 29 «Виртуальные 
конструкторы и Прототип»). 


Тема 14 | Указатели на функции 


Можно объявить указатель на функцию конкретного типа. 
\019 (*#р) (іп); // указатель на функцию 


Обратите внимание на обязательные круглые скобки, показывающие, 
что Гр — это указатель на функцию, которая возвращает \019, а не \о14 * 
(см. тему 17 «Разбираемся с операторами объявления функций и масси- 
вов»). Как и указатель на данные, указатель на функцию может быть ну- 
левым или ссылаться на функцию соответствующего типа. 


ехЕегп іпі #( 111 ); 
ехіөгп уоіа 9( 1опд ); 
ехЕегп моіа һ( іп ); 


а 

р = Ф; // ошибка! &Р типа іпі(*) (іп), не уо19(*) (іп) 
Тр = 9; //ошибка! &9 типа \019(*)(10п49), не моіад(+) (111) 
фр = 0; // ОК, присваивается нуль 

Тр = һ // ОК, указывает на һ 


Тр = &1; // ОК, явно принимает адрес 


Заметьте, что необязательно явно извлекать адрес функции при инициа- 
лизации или присваивании ее адреса указателю на функцию. Компиля- 
тор знает, что необходимо получить адрес функции, поэтому в данном 
случае оператор & может отсутствовать. 


Точно так же можно не разыменовывать указатель на функцию, чтобы 
вызвать функцию, на которую он ссылается, потому что компилятор сде- 
лает это сам: 


(+#р) (12); // явное разыменование 
#р(12); // неявное разыменование, результат аналогичен 
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Обратите внимание, что не существует универсальных указателей, спо- 
собных указывать на функции любого типа, как указатель уоій *х может 
ссылаться на любой тип данных. Еще необходимо отметить, что адрес не- 
статической функции-члена — это не указатель, поэтому указать на нее 
с помощью указателя на функцию невозможно (см. тему 16 «Указатели 
на функции-члены – это не указатели»). 


Традиционно указатели на функции служат для реализации обратных 
вызовов (более эффективные реализации обратных вызовов продемонст- 
рированы в темах 18 «Объзекты-функции» и 19 «Команды и Голливуд»). 
Обратный вызов – это потенциальное действие, которое задается на эта- 
пе инициализации, чтобы быть вызванным в ответ на будущее событие. 
Например, если необходимо отреагировать на пожар, лучше заранее 
спланировать, как действовать в этом случае: 


ехїегп \014 ѕіорргорВо11(); 


іпііпе №019 јитр1п() { ... } 

Е 

уоіа (*#ігеАс+іоп)() = 0; 

Иа 

1Р( ! Ғаа1іѕі ) { // если вам не безразлично, что вы горите. . 


// на всякий случай задайте соответствующее действие 
1Е( пеагматег ) 

Ғі геАсїіоп = јитрІп 

е1зе 
Т1 геАсїіоп = эфорОгорВо11 


} 


Определив порядок действий, в другой части кода можно указать, когда 
и вкаком случае его выполнять, не заботясь о сути действия: 


1Р( Ртетр >= 451 ) { // если возник пожар. . 
1Р( ҒігеАс+іоп ) //...и необходимо выполнить действие... 
#1 геАсїіоп(); // ...выполнить его! 


} 


Допускается указатель на встраиваемую функцию. Однако вызов встраи- 
ваемой функции через указатель на функцию невозможен, потому что 
в общем случае компилятор неспособен во время компиляции точно опре- 
делить, какая функция будет вызываться. В нашем предыдущем примере 
ҒігеАсііоп (действие при пожаре) может указывать на любую из двух 
функций (или ни на одну из них); таким образом, в точке вызова компи- 
лятору ничего не остается, как сгенерировать код для непрямого вызова 
невстраиваемой функции. 


Можно получить и адрес перегруженной функции: 


уоіа ]итрТп(); 


Указатели на функции 63 


№019 ]итрТп( 6001 сап$міт ); 


//... 


ҒігеАстіоп = дитрТп; 


Тип указателя применяется для осуществления выбора функции из пред- 
лагаемых возможных. В данном случае [1 геАсііоп имеет тип \019(*)(), та- 
ким образом, выбирается первая функция јитрІп (запрыгнуть). 


В стандартной библиотеке указатели на функции выступают в качестве 
обратных вызовов в нескольких случаях. Самый примечательный - стан- 
дартная функция ѕеї пен һапд1ег. Она задает обратный вызов, который 
должен быть инициирован, если глобальная функция орегаїог пем не мо- 
жет выделить память по запросу. 


уоіа БедРогд1\епезз() { 
109Еггог( "Ѕоггу!" ); 
їһгом 51а: : раа _а110с(); 

} 

ИИ 


эта: : пем һапа1ег о1аНапа1ег = 
а: :ѕеі пем һапаї1ег(бедғЕогодімепеѕѕ); 


Стандартное имя типа для пем һапа1ег — фуредет: 
уреде? уоіа (*пем һапа1ег)(); 


Следовательно, обратный вызов должен быть функцией, не принимаю- 
щей аргументы и возвращающей \0149. Функция ѕеї пем һапд1ег присваи- 
вает функцию обратного вызова своему аргументу и возвращает предыду- 
щий обратный вызов. Отдельной функции для получения и задания нет. 
Получение текущей функции обратного вызова напоминает хождение по 


кругу: 
51а: : пем ћһапд1ег сиггепї 
= ѕїа::зеї пем һапа1ег( 0 ); // получаем... 
$14: :ѕеі пем һапа1ег( сиггепі ); // ...и возвращаем в исходное состояние! 


Стандартные функции 56ї іегтіпаїе и зе{_ипехрестед следуют такой же 
схеме комбинированного получения и задания обратного вызова. 


Тема 15 | Указатели на члены класса – 
это не указатели 


Слово «указатель» в описаниях указателей на члены класса неуместно. 
Они не содержат адресов и ведут себя не как указатели. 


Синтаксис объявления указателя на член не так уж и плох (если вы успе- 
ли привыкнуть к синтаксису объявления обычных указателей): 


іпі *10; // указатель на іпї 
іпі С::*р1тС; // указатель на член типа іпї класса С 


Единственное отличие в том, что символ *, заменяется на имя_класса: :*, то 
есть имеет место ссылка на член класса имя_класса. Во всем остальном син- 
таксис аналогичен обычному объявлению указателя. 


\014 * * хсопѕ1 * меіга1; 
үоій *А: :*В::хсопѕі * ме1га2; 


меіга1 — это указатель типа «указатель на константный указатель на ука- 
затель на указатель на уоій». меігӣ2 — это указатель типа «указатель на 
константный указатель на член В на указатель на член А, который являет- 
ся указателем на \014». (Это всего лишь пример, обычно такие сложные 
или нелепые описания не встречаются.) 


Обычный указатель содержит адрес. При разыменовании указателя по- 
лучаем объект, находящийся по этому адресу: 

іпі а = 12; 

1р = ёа; 

*1р = 0; 

а = *1р; 
Указатель на член, в отличие от обычного указателя, не ссылается на 
конкретную область памяти. Он ссылается на конкретный член класса, 
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но не на конкретный член конкретного объекта. Поэтому обычно указа- 
тель на член данных считают смещением. Это не обязательно, потому что 
стандарт С++ ничего не говорит о том, как должен быть реализован ука- 
затель на член данных, оговариваются только его синтаксис и поведение. 
Однако большинство компиляторов реализуют указатели на члены дан- 
ных как целое, содержащее значение, равное смещению до указываемого 
поля плюс один. (Смещение инкрементируется для того, чтобы значени- 
ем 0 представлять нулевой указатель на поле.) Смещение указывает, на 
сколько байтов от начала объекта смещен конкретный член. 


с1а55 С { 
рир11с: 

ан 
іпї а_; 

}; 

11 С::*р1тС; // указатель на член С типа іпї 

С ас; 

С *рС = вас; 

р1тС = &С::а_; 

ас. +*рітб = 0; 

іпї р = рС->*р1тС; 


Присваивая ріпс значение &С: :а_, мы в сущности задаем в ріпс смещение 
а_ в рамках С. Давайте разберемся. Если а_ не статический член, примене- 
ние & в выражении &С: :а_ возвращает нам не адрес, а смещение. Обратите 
внимание, что это смещение применяется к любому объекту типа С. То 
есть если член отстоит на 12 байт от начала в одном объекте С, то на те же 
12 байт он будет отстоять и от начала любого другого объекта С. 


Чтобы обратиться к члену данных, имея в распоряжении его смещение 
в рамках класса, нам необходим адрес объекта этого класса. Вот где появ- 
ляются необычные на вид операторы .* и ->*. Записывая рс->*ріпс, мы 
увеличиваем адрес, хранящийся в рс, на смещение, хранящееся в р1тС, 
чтобы организовать доступ к соответствующему члену данных объекта С, 
на который ссылается рс. Записывая ас. *р1тС, мы увеличиваем адрес аб на 
смещение, хранящееся в ріпс, чтобы организовать доступ к соответствую- 
щему члену данных объекта С, на который ссылается рс. 


Указатели на члены данных используются не так широко, как указатели 
на функции-члены, но они позволяют наглядно проиллюстрировать по- 
нятие контрвариантности. 


Имеет место предопределенное преобразование указателя на производ- 
ный класс в указатель на любой из его открытых базовых классов. Часто 
говорят, что между производным классом и его открытыми базовыми 
классами устанавливается отношение «является». Это отношение часто 
вытекает естественным образом из анализа предметной области (см. те- 
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му 2 «Полиморфизм»). Следовательно, можно утверждать, что, напри- 
мер, Сігс1е (Круг) является Эпаре (Форма) посредством открытого насле- 
дования. И С++ поддерживает нас, предоставляя неявное преобразование 
Сігс1е * в Ѕһаре *. Неявного преобразования паре * в Сігс1е * нет, потому 
что такое преобразование не имело бы смысла. Может существовать мно- 
го разных типов Ѕһаре, и не все они являются Сігс1е. (К тому же глупо зву- 
чит: «Форма является кругом».) 


В случае с указателями на члены класса наблюдается обратная ситуация: 
есть неявное преобразование указателя на член базового класса в указа- 
тель на член открытого производного класса, но нет преобразования ука- 
зателя на член производного класса в указатель на член любого из его ба- 
зовых классов. Эта концепция контрвариантности кажется нелогичной, 
если только не вспомнить о том, что указатель на член данных не являет- 
ся указателем на объект. Это смещение в объекте. 


с1аѕѕ Ѕһаре { 
а 
Роіпі сепфег_; 
ИИ 
}; 
с1аѕѕ Сігс1е : рир1іс Ѕһаре { 
//... 
доир1е гадіџиѕ _; 
ИА 


}; 


Сігс1е представляет собой Ѕһаре, таким образом, объект Ѕһаре содержит 
подобъект Сігс1е. Следовательно, любое смещение в рамках Ѕһаре дейст- 
вительно также и в (ігс1е. 


Роіпі Сігс1е::*10с = &5һаре::сепіег_; // ОК, базовый к производному 


Однако Ѕһаре необязательно представляет собой Сігс1е, таким образом, 
смещение члена Сігс1е не всегда действительно в рамках Ѕћһаре. 


доир1е Ѕһаре: :*ехїепї = 
&Сігс1е: : га91и$_; // ошибка! производный к базовому 


Нелишним будет отметить, что в Сігс1е есть все члены данных его базово- 
го класса ЭПаре (т. е. он наследует эти члены от паре). С++ поддерживает 
неявное преобразование указателя на член Ѕһаре в указатель на член Сігс- 
1е. Нельзя сказать, что Ѕ5ћаре содержит все члены данных Сігс1е (Зпаре ни- 
чего не наследует от Сігс1е). И С++ напоминает об этом, запрещая преоб- 
разование указателя на член Сігс1е в указатель на член Ѕћаре. 


Тема 16 | Указатели на функции-члены - 
это не указатели 


Принимая адрес нестатической функции-члена, вы получаете не адрес, 
а указатель на функцию-член. 


с1аѕѕ Ѕһаре { 
рир11с: 
аы 
уоіа тоуето( Роіпі пем оса+іоп ); 
роо1 уа1іда+е() сопѕ+; 
уігіџа1 6001 дгам() сопѕї = 0; 


Е 

}; 

с1аѕѕ Сігс1е : рир1іс Ѕһаре { 
И 
6001 Чгам() сопѕ+; 
к 


}; 
а 


\014 (Ѕһаре: : *т#?1)( Роіпї ) = &Эпаре: :тоуеТо; // не указатель 


Синтаксис объявления указателя на функцию-член на самом деле не 
сложнее, чем синтаксис объявления указателя на обычную функцию (ко- 
торый, надо сказать, не очень удачен; см. тему 17 «Разбираемся с опера- 
торами объявления функций и массивов»). Как и для указателей на дан- 
ные-члены, необходимо использовать не +, а имякласса, тем самым пока- 
зывая, что функция, на которую ссылаются, является членом имякласса. 
Однако, в отличие от обычного указателя на функцию, указатель на 
функцию-член может ссылаться на константную функцию-член: 


роо1 (ЗПаре: :*хпР2)() сопѕї = &5һаре: :уа11даїе; 
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Как и с указателем на данные-член, чтобы разыменовать указатель на 
функцию-член, необходим объект или указатель на объект. В случае с ука- 
зателем на данные-член, чтобы организовать доступ к члену, к его смеще- 
нию (содержащемуся в указателе на данные-член) необходимо добавить 
адрес объекта. В случае с указателем на функцию-член необходим адрес 
объекта, чтобы использовать его (или вычислить; см. тему 28 «Смысл 
сравнения указателей») как значение указателя 111$ для вызова функции 
и, возможно, других целей. 


Сігс1е сігс; 

Ѕһаре *рЅһаре = &сігс; 

(р$һаре->*т#2)(); // вызываем Ѕһаре: :уа1ійаїе 
(сігс.*т#2)(); // вызываем Ѕһаре: :уа11дате 


Операторы ->* и .* должны быть заключены в круглые скобки, потому 
что они имеют меньший приоритет, чем оператор (). И прежде чем вызы- 
вать функцию, необходимо выяснить, какую функцию вызывать! Это 
абсолютно аналогично использованию круглых скобок в выражении 
(а+р)*с, где мы хотим, чтобы сложение выполнялось раньше, чем умно- 
жение, имеющее больший приоритет. 


Обратите внимание, что нет такого понятия, как «виртуальный указа- 
тель на функцию-член». Виртуальность — свойство самой функции-чле- 
на, а не указателя, ссылающегося на нее. 


тЁ2 = ё9һаре::агам; // гам виртуальная 
(рЅћаре->*т#2)(); // вызываем Сігс16: : гам 


Есть одна причина, по которой указатель на функцию-член не может 
быть реализован в общем случае как простой указатель на функцию. Реа- 
лизация указателя на функцию-член должна сохранять в себе следую- 
щие сведения: 


® является ли функция-член, на которую он ссылается, виртуальной 
или невиртуальной; 


® где искать соответствующий указатель таблицы виртуальных функ- 
ций (см. тему 11 «Компилятор дополняет классы»); 


• какое смещение должно добавляться к указателю 111$ функции или 
вычитаться из него (см. тему 28 «Смысл сравнения указателей»); 


• возможно, другую информацию. 


Указатель на функцию-член обычно реализуется как небольшая структу- 
ра, содержащая всю эту информацию, хотя используются и многие дру- 
гие реализации. Разыменование и вызов указателя на функцию-член 
обычно включает проверку хранящейся информации и в зависимости от 
условий выполнение соответствующей последовательности вызовов вир- 
туальной или невиртуальной функции. 
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Как и указатели на данные-члены, указатели на функции-члены демон- 
стрируют контрвариантность: существует предопределенное преобразо- 
вание указателя на функцию-член базового класса в указатель на функ- 
цию-член производного класса, но не наоборот. Это имеет смысл, если 
предполагается, что функция-член базового класса посредством указате- 
ля {11$ будет организовывать доступ только к членам базового класса, то- 
гда как функция производного класса может делать попытки доступа 
к членам, не присутствующим в базовом классе. 


с1а55 В { 

рир11с: 
уоіа 6ѕеї( іпі ма1 ) { Буа1_ = уа1; } 
ргімаїе 
іп руа1_; 
}; 
с1аѕѕ 0 : рир1іс В { 

рир11с: 
үоіа 056ї( іпі ма1 ) { 4\а1_ = уа1; } 
ргімаїе: 
іп ауа1_; 


}; 

В б; 

ра; 

моїа (В::*#1) (іп) = &0::9зе1; // ошибка! производная функция в указателе 
// на базовый класс 

(0.*#1)(12); // ой! Доступ к несуществующему члену а\а1 

моіа (0::+*#2) (іп) = &В::рѕеї, // ОК, базовая функция в указателе 
// на производный класс 

(а. *#2)(11); // ОК, записываем в унаследованное поле руа1 


Тема 17 | разбираемся с операторами 
объявления функций и массивов 


Основной причиной путаницы с объявлениями указателей на функции 
и указателей на массивы является более высокая приоритетность моди- 
фикаторов функции и массива, чем модификатора указателя. Поэтому 
часто приходится использовать круглые скобки. 


ТП *#1(); // функция, возвращающая іпї + 
іп (*#р1)(); // указатель на функцию, возвращающую іп 


Та же проблема существует и с модификатором массива, имеющим более 
высокий приоритет: 


Соп$Е 11 № = 12; 
Тип *аї[№]; // массив из № элементов типа іпї * 
іп (+ар1)[№]; // указатель на массив, состоящий из № целых элементов 


Конечно, если может существовать указатель на функцию или массив, то 
может существовать и указатель на этот указатель: 


іпі (х*ар2) [№]; // указатель на указатель на массив 

// состоящий из № элементов типа іп 
іп *(*арз) [№]; // указатель на массив, состоящий из № элементов типа іпі + 
іпі (х*сопзі #р2)() = 0; // константный указатель на указатель на функцию 
ілі *(*#р3)(); // указатель на функцию, возвращающую іпі * 


Заметьте, что тип функции или указателя на функцию зависит и от аргу- 
мента, и от возвращаемых типов. 


сһаг *(*#р4) (іп, 111); 
сһаг *(*#р5)(ѕһогі, ѕһогї) = 0; 
#р4 = #р5; // ошибка! несоответствие типов 
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Сложности появятся, если модификаторы функции и массива окажутся 
в одном объявлении. Рассмотрим следующую распространенную и невер- 
ную попытку объявить массив указателей на функцию: 


іп (х) ()ағр1[№]; // синтаксическая ошибка! 


В приведенном выше (неправильном) объявлении модификатор функции 
() завершает объявление, а добавленное дальше имя аѓрі обозначает нача- 
ло синтаксической ошибки. Это аналогично такому объявлению массива: 


іп а2; // синтаксическая ошибка! 


которое вполне работоспособно в Јауа, но недопустимо в С++. При пра- 
вильном объявлении массива указателей на функцию объявляемое имя 
указывается там же, где и в простом указателе на функцию. Затем гово- 
рится, что необходимо создать массив этих указателей: 


іпі (хаРр2[№])(); // массив из № указателей на функцию, 
// возвращающую элементы типа іп 


Выражения становятся слишком громоздкими, поэтому пора обратиться 
к їуредеғ. 


уреде? іпі (*ЁЕР)(); // указатель на функцию возвращает элемент типа іпі 
ЕР а?рз[№]; // массив № элементов ЕР того же типа, что и а#р2 


Применение Туреде! для упрощения синтаксиса сложных объявлений — 
это знак заботы о тех несчастных, которые будут работать с кодом после 
вас. С туреде! упрощается даже объявление стандартной функции ѕеї_ 
пем_һапа1ег: 


уреде? уоіа (*пем һапд1ег)(); 
пем_һапд1ег ѕеї пем һапа1ег( пем һапд1ег ); 


Таким образом, пем һапд1ег (см. тему 14 «Указатели на функции») – это 
указатель на функцию, не принимающую аргументы и возвращающую 
уо1а. ѕеї пем һапд1ег - это функция, принимающая пем һапд1ег как аргу- 
мент и возвращающая пем_һапі1ег. Все просто. Если сделать все это без їу- 
рейе#, ваша популярность среди тех, кому придется обслуживать ваш 
код, стремительно упадет: 


№019 (*ѕеї пем һапд1ег(моїіа (*)()))(); // правильно, но жестоко 


Также можно объявить ссылку на функцию. 


іпі ағипс( доир1е ); // функция 
іп (&гРипс) (доџр1е) = аРипс; // ссылка на функцию 
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Ссылки на функции применяются редко и заполняют примерно ту же ни- 
шу, что и константные указатели на функции: 


іп (хсопѕі рЕипс) (доир1е) = аРипс; // константный указатель на функцию 


Ссылки на массивы обеспечивают некоторую дополнительную возмож- 
ность, не предоставляемую указателями на массивы, и обсуждаются в те- 
меб «Массив как тип формального параметра». 


Тема 18 | Объекты-функции 


Часто нам требуется что-то, что действовало бы аналогично указателю на 
функцию. Но указатели на функции слишком неуклюжи, опасны и (да- 
вайте согласимся с этим) давно устарели. Как правило, их с успехом заме- 
няют объекты-функции. 


Объект-функция, как и умный указатель (см. тему 42 «Умные указате- 
ли»), – это обычный объект класса. Тогда как тип умного указателя пере- 
гружает операторы -> и * (и, возможно, ->*), чтобы сымитировать «прока- 
чанный указатель» (роп\фег оп ѕегоійѕ, улучшенный, более функциональ- 
ный), тип объекта-функции перегружает оператор вызова функции (), 
чтобы создать «прокачанный указатель на функцию». Рассмотрим объ- 
ект-функцию, вычисляющий при каждом вызове следующий элемент об- 
щеизвестного ряда Фибоначчи (1, 1, 2, 3, 5, 8, 18...): 


с1аѕѕ Рір { 

рир11с: 
Рір() : ао (1), аї (1) {} 
іпі орега+ог ()() 
ргімаїе: 
іп а0_, а1_ 


5 


іп Бір: :орега+ог ()() { 
іп +етр = а0_; 


а0_ = аї; 
а1_ = Тетр + а0_; 
гефигп Тетр 


} 


Объект-функция - это всего лишь обычный объект класса, но его член оре- 
гаїог () (или члены, если их больше одного) можно вызывать с помощью 
стандартного синтаксиса вызова функции. 
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Рір 116; 

И 

сои << "пехї їмо іп зег1ез: " << 1160) <<‘ 
сои << 116() << өепа1; 


Компилятор распознает синтаксис ѓір() как вызов функции-члена орега- 
їог() переменной 116. По смыслу этот вызов идентичен 110. орегаїог(), но, 
вероятно, проще для восприятия. В данном случае преимущество объек- 
та-функции перед функцией или указателем на функцию в том, что со- 
стояние, необходимое для вычисления следующего элемента ряда Фибо- 
наччи, хранится в самом объекте Гір. Функции для сохранения состояния 
между вызовами пришлось бы прибегнуть к глобальным или локальным 
статическим переменным или какому-нибудь другому трюку. Возможно, 
информацию пришлось бы передавать в функцию явно. Также следует об- 
ратить внимание, что, в отличие от функции, использующей статические 
данные, в этом случае можно иметь одновременно несколько объектов 
Рір, осуществляющих вычисления независимо друг от друга. 


11 Ғіропассі () { 
ѕ+аїіс іпї а0 = 0, аї = 1; // проблематично. . 
іп 1етр = ао; 
а0 = а1; 
а1 = Тетр + а0; 
гефигп фетр 


} 


Также есть весьма популярная возможность создать эффект указателя на 
виртуальную функцию, образуя иерархию объекта-функции с помощью 
виртуального оператора орегаїог(). Рассмотрим вычисление интеграла 
методом аппроксимации площади под кривой, как показано на рис. 18.1. 


Д 


| > 
10м Те 
(нижняя граница) (верхняя граница) 


Рис. 18.1. Численное интегрирование путем суммирования площадей 
прямоугольников (упрощенное) 
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Для приближенного вычисления площади под кривой как суммы площа- 
дей прямоугольников (или реализации подобного механизма) функция 
интегрирования будет итеративно вызывать функцию для значений, на- 
ходящихся между нижней и верхней границами. 


уреде? доџир1е (*Е)( доир1е ); 
аоир1е іпіедгате( Е #, доче 1ом, доир1е һідћ ) { 
сопї іпї пимотерз = 8 
доир1е ѕїер = (һідһ-10м) /пит$+ерѕ; 
поир1е агеа = 0.0; 
мһі1е( 1ом < һідһ ) { 
агеа += #( 1ом ) * ѕіер; 
10м += 5їер; 
} 
гефигп агеа; 


} 


В этой версии передается указатель на функцию, для которой предпола- 
гается осуществить интегрирование. 


аоир1е аҒипс( доџр1е х ) {... } 


Иа 
доир1е агеа = іпїедга+е( ағипс, 0.0, 2.71828 ); 


Такой вариант работоспособен, но негибок, потому что интегрируемая 
функция обозначается при помощи указателя на функцию. Этот код не 
может оперировать функциями, которым необходимы состояние или 
указатели на функции-члены. Альтернатива — создание иерархии объек- 
та-функции. Базовым классом иерархии будет простой интерфейсный 
класс, объявляющий чистую виртуальную функцию орегаіог(). 


с1аѕѕ Рипс { 
рир11с: 

уігіџа1 "Рипс(); 

уігіџа1 йоир1е орегафог ()( доџр1е ) = 0; 
}; 
доир1е іпіедгаїте( Гипс &#, йоир1е 1ом, доир1е һідһ ); 
Теперь функция іпїедгаїе способна интегрировать объект-функцию лю- 
бого типа, который является Ғипс (см. тему 2 «Полиморфизм»). Также ин- 
тересно отметить, что тело іпіедгате вообще не надо менять (хотя требует- 
ся повторная компиляция), потому что синтаксис вызова объекта-функ- 
ции тот же, что и для указателя на функцию. Например, можно создать 
производный от Гипс тип, способный обрабатывать функции, не являю- 
щиеся членами: 


с1аѕѕ ММЕипс : риуб]1с Рипс { 
рир11с: 
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ММРипс( доџр1е (*Р)( доџр1е ) ) : # (Ж) {} 
доир1е орега+ог ()( доџир1е а ) { гефит # (а ); } 
ргімаїе: 
доир1е (*#_)( аоџр1е ); 
}; 


Это позволяет интегрировать все функции исходной версии: 


доир1е аРипс( адоир1е х ) {... } 

а 

ММЕипс 9( ағипс ); 

доир1е агеа = іпіедгаїе( д, 0.0, 2.71828 ); 


Также функции-члены можно интегрировать, заключая указатель на 
функцию-член и объект класса в соответствующий интерфейс-обертку 
(см. тему 16 «Указатели на функции-члены – это не указатели»): 


Тетр1афе <с1а55 С> 
с1аѕѕ МЕупс : рир21іс Рипс { 
рир11с: 
МЕипс( С &00ј, Яоир1е (С: : *#) (доир1е) ) 
: 063_(063), Ё (#) 4) 
доир1е орегаїог ()( доџшр1е а ) 
{ гефиги (о6ј_.*#)(а ); } 


ргімаїе: 
С &00ј_; 
доир1е (С::*#_)( доџир1е ) 
}; 
//... 


АС1а55 ап00ј; 
МЕипс<АС1а5$5> #( ап0б], &АС1азз: :аРипс ); 
доир1е агеа = іпіедгаїе( #, 0.0, 2.71828 ); 


Тема 19 | Команды и Голливуд 


Если объект-функция выступает в качестве функции обратного вызова, 
это экземпляр паттерна Команда (Соттапа). 


Что такое обратный вызов? Предположим, вы отправляетесь в длитель- 
ное путешествие и я одалживаю вам свою машину. Зная ее состояние, я, 
наверное, также дам вам запечатанный конверт с номером телефона и по- 
рекомендую позвонить по нему, если возникнут проблемы с двигателем. 
Это обратный вызов. Вам не надо знать номер телефона заранее (это мо- 
жет быть телефон хорошей станции техобслуживания, автобусной линии 
или городской свалки), и, кстати, он может вообще не понадобиться. 
В сущности задача по разрешению «проблемы с двигателем» распределе- 
на между вами (или «каркасом») и мной (или «клиентом каркаса»). Вы 
знаете, когда следует сделать что-то, но не знаете, что делать. Я знаю, что 
делать в случае конкретного события, но не знаю, когда делать. Вместе 
мы образуем единое целое. 


Обратные вызовы — это распространенная техника программирования, 
которая обычно реализуется через простые указатели на функции (см. те- 
му 14 «Указатели на функции»). Рассмотрим интерактивный тип Ви Топ, 
отображающий на экране кнопку с надписью и выполняющий действие 
при щелчке по ней. 


с1аѕѕ Виї+оп { 
рир11с: 
Вит Еоп( сопѕї ѕїгіпо &1аре1 ) 
1аре1 (1аре1), ас+ііоп (0) {} 


7Виттоп {... де1ете асїіоп_; ...} 
уоіа ѕеТАсїіоп( уоіад (хпемАс+іоп)() ) 
{ асііоп_ = пемАсііоп; } 


№019 опС1іск() сопзі 
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(ассо) зон) № 
ргіуаїте: 
ѕїгіпо 1абе1_; 
уоіа (хас1оп_)(); 


ва 
1 


Пользователь Виїїоп задает функцию обратного вызова и затем передает 
управление Виїїоп коду каркаса, который может определять момент на- 
жатия кнопки и выполнять действие. 


ехЕегп \014 ріауМиѕіс(); 

а 

Витоп *р = пем Виїт+оп( "Апоко по патаема” ); 
р->ѕе+Асїіоп( р1ауМиз1с ); 
гедіѕтегВи+топиі+ћЕгатемогк( 0 ); 


Такое разделение обязанностей часто называют принципом Голливуда: 
«Не звоните нам, мы сами вам позвоним». Мы настраиваем кнопку на вы- 
полнение определенного действия в случае нажатия. Код каркаса знает, 
ЧТО ЭТО действие должно быть инициировано при нажатии кнопки. 


Однако применение простого указателя на функцию в качестве функции 
обратного вызова имеет строгие ограничения. Функции часто обрабаты- 
вают некоторые данные, но с указателем на функцию не ассоциированы 
никакие данные. Откуда функция р1ауМиз1с (воспроизвести музыку) из 
предыдущего примера может знать, какую песню воспроизводить? Что- 
бы быстро решить эту задачу, обычно либо строго ограничивают область 
применения функции 


ехЕегп \014 р]ауАпокоМоМатаема(); 


ИИ... 


р->ѕеАстіоп( р1ауАпокоћоМћатаема ); 


либо прибегают к сомнительной и опасной практике применения гло- 
бальной переменной: 


ехїегп сопзф МРЗ хћебиггепЅопо = 0; 


ИИ... 


сопзі МРЗ апоко№оМатаема ( "АпокоМоМатаема. трз” ); 
ТһебиггепіЅопо = &апокоћоћатаема; 
р->ѕеАстіоп( р1ауМиз1с ); 


Как правило, вместо указателя на функцию лучше применять объект- 
функцию. Объект-функция – или чаще иерархия объектов-функций — 
в сочетании с принципом Голливуда образует экземпляр паттерна Коман- 
да. 
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Очевидное преимущество объектно-ориентированного подхода состоит 
в том, что объект-функция может инкапсулировать данные. Другой по- 
ложительный момент — объект-функция может обладать динамическим 
поведением, посредством виртуальных членов. То есть возможна иерар- 
хия взаимосвязанных объектов-функций (см. тему 18 «Обзекты-функ- 
ции»). Есть и третий плюс, но он будет рассмотрен позже. А пока дорабо- 
таем Виїїоп с применением паттерна Команда: 


с1аѕѕ Ас+іоп { // паттерн Команда 
рир11с: 
уігіџа1 Ас+іоп() 
үуігіџа1 у019 орегаїог ()() = 0; 
уігіџа1 Асііоп *с10опе() сопзЕ = 0; // Прототип 
}; 
с1аѕѕ Виї+оп { 
рир11с: 
Витоп( сопѕї 51а: :ѕігіпо &1аре1 ) 
: 1аре1 (1аре1), ас+іоп (0) {} 
7Витоп {... еІеїе астіоп_; ...} 
уоіа ѕеАсїіоп( сопзЕ Асііоп *пемАсїіоп ) { 
Ас+іоп *+етр = пемАс+1іоп->с1опе() 
де1ете ас+Тіоп_; 
асїііоп_ = їетр 


} 
уоіа опС11ск() сопзЕ 
{ іР( асіїіоп_ ) (*асїіоп_)(); } 
рг1\мате: 
51а: :51гіпо 1абе1_; 
Ас+іоп *асї1іоп_; // Команда 


Иры 


}; 


Теперь Виїтоп может работать с любым объектом-функцией, представля- 
ющим собой Асііоп, например таким: 


с1аѕѕ Р1ауМиѕіс : руб11с Ас+іоп { 
рир11с: 
Р1ауМиѕіс( сопзЕ 51а: :ѕігіпо &ѕопдЕі1е ) 
: ѕопо_ (ѕопоРі1е) {} 
уоіа орега+ог ()(); // воспроизводит песню 
ЕЕ 
ргімаїе: 
МРЗ ѕопо_; 
}; 


Инкапсулированные данные (в данном случае воспроизводимая песня) 
обеспечивают и гибкость, и безопасность объекта-функции Р1аумиѕіс. 
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Витоп *р = пем Виффоп ("Апоко по патаема”); 
р->ѕетАс+іоп (&Р1ауМиѕіс ("АпокоћоМ№атаема. трз”)); 1 


Так что же это за таинственное третье преимущество паттерна Команда, 
о котором упоминалось ранее? Работать с иерархией классов удобнее, чем 
с более примитивной и менее гибкой структурой указателя на функцию. 
Наличие иерархии паттерна Команда позволило сочетать паттерн Прото- 
тип (Ргобофуре) с паттерном Команда, для того чтобы создавать клонируе- 
мые команды (см. тему 29 «Виртуальные конструкторы и Прототип»). 
Можно продолжать в том же духе и, комбинируя паттерны Команда и Про- 
тотип, создавать новые паттерны, обеспечивая тем самым дополнительную 
гибкость. 


1 Возможно, не все компиляторы обрадуются получению ссылки на временный 
объект. Для этого случая есть альтернативный код: 
Р1ауМиѕіс рт (“АпокоМ№оМатаема. рз”); 
р->ѕе+Астіоп (&рт); 


Тема 20 | объекты-функции $ТЕ 


Как вообще можно было обходиться без БТТ? Она не только упрощает 
и ускоряет написание сложного кода, но и позволяет получить стандар- 
тизованный и высоко оптимизированный код. 


ѕ1а: : местог<$та: :3{г1п9> папеѕ 


//... 


$14: :ѕогі( патеѕ. редіп(), патез.епа() ); 


Еще одно замечательное свойство библиотеки ТІ, в том, что она легко на- 
страивается. В приведенном выше коде для сортировки вектора строк 
применялся оператор класса $1г1пд «меньше чем». Но не всегда этот опе- 
ратор есть в распоряжении или, возможно, не всегда требуется сортиров- 
ка по возрастанию. 


с1аѕѕ офате { 
рир1іс: 
ам 


іпї рори1а+іоп() сопѕї; 
Ғ1оаї амеТетрЕ() сопѕї; 


Е 
}; 

В классе Ѕїаїе (который представляет штат государства) нет оператора 
«меньше чем». Наверное, и необходимости его реализовывать нет, потому 
что непонятно, что значит для одного штата быть меньше другого (сравни- 
ваются имена, население, процентное соотношение депутатов, находя- 
щихся под следствием, и т. д.). К счастью, ЭТГ позволяет в подобных си- 
туациях определять альтернативную операцию, подобную «меньше чем». 
Такие операции называются компараторами, потому что в них сравни- 
ваются два значения: 


іпііпе 6001 роріеѕ5( сопѕі эфафе ёа, сопѕї ЗТафе &6 ) 
{ гефигп а. рориїатіоп() < 6. рори1а{1оп(); } 
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Создав компаратор для $їаіе, можно использовать его для сортировки: 


ЭТафе эфафез[50]; 
е 


ѕіа::ѕогі( ѕіатеѕ, ѕїаіеѕ+50, роріеѕѕ ); // по населению 


Здесь в качестве компаратора передается указатель на функцию роріеѕѕ 
(вспомните, что при передаче в качестве аргумента имя функции разлага- 
ется в указатель на функцию; так же и имя массива ѕіаїеѕ разлагается 
в указатель на его первый элемент). Поскольку роріеѕѕ передается как 
указатель на функцию, она не будет встроена в $0гї, что нежелательно, 
если важна скорость сортировки (см. тему 14 «Указатели на функции»). 


Ситуацию можно исправить, применив в качестве компаратора объект- 
функцию: 


ѕігисі Роріеѕѕ : рир1іс 51а: : ріпагу Ғипсїіоп <Ѕ+аїте, Зтате, роо1> { 
6001 орега+ог ()( сопѕї Эфафе ва, сопѕі Ѕїаїте &6 ) сопзЕ 
{ геъигп рор[еѕѕ( а, р ); } 
}; 


Тип Роріеѕѕ — это характерный пример правильно построенного объекта- 
функции БТГ.. Во-первых, это объект-функция. Он перегружает оператор 
вызова функции, поэтому может быть вызван с помощью обычного син- 
таксиса вызова функции. Это важно, потому что универсальные алгорит- 
мы ТІ, такие как ѕогі, написаны таким образом, что для создания их эк- 
земпляра может использоваться как указатель на функцию, так и объ- 
ект-функция, при условии, что к ним применим обычный синтаксис 
вызова функции. Объект-функция с перегруженным орегаїог() удовлет- 
воряет этому синтаксическому требованию. 


Во-вторых, он является производным от стандартного базового класса рі - 
пагу _#ипс+іоп. Этот механизм позволяет другим частям реализации БТІ, об- 
ращаться к объекту-функции во время компиляции (см. тему 53 «Встро- 
енная информация о типе»). В данном случае происхождение от ріпагу_ 
РГипс1оп обеспечивает возможность получать информацию о типе аргумен- 
та и возвращаемом типе объекта-функции. Хотя здесь эта возможность не 
задействуется, с уверенностью можно сказать, что ее будет использовать 
кто-то другой, ведь мы хотим, чтобы нашим типом Рор6еѕѕ пользовались 
остальные. 


В-третьих, у объекта-функции нет данных-членов, нет виртуальных функ- 
ций, нет прямо объявленных конструкторов или деструктора и реализа- 
ция орегаїог () встраиваемая. Выступающие в качестве компараторов 
БТІ, объекты-функции должны быть компактными, простыми и быстры- 
ми. Можно создавать объекты-функции ТІ, с довольно большими реали- 
зациями, но в основном это нецелесообразно. Другая причина сведения 
к минимуму или отказа от использования данных-членов в объекте-функ- 
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ции, предназначаемой для работы с БТГ, состоит в том, что реализации 
ӨТІ, могут создавать несколько копий объекта-функции и предполагать 
идентичность всех этих копий. Проще всего гарантировать идентичность 
всех копий обекта, если объект не имеет данных вообще. 


Теперь можно осуществить сортировку с помощью объекта-функции: 
ѕогі( зфафез, зфафез+50, Роріеѕѕ() ); 


Обратите внимание на круглые скобки, стоящие после Роріеѕѕ в данном 
вызове. Роріеѕѕ — это тип, но объект этого типа приходится передавать 
как аргумент функции. Добавляя круглые скобки после имени типа Рор- 
[езз, мы создаем безымянный временный объект Роріеѕ5, существующий 
в течение вызова функции. (Эти безымянные объекты называют аноним- 
ными временными объектами (апопутоиз 1етрогагу); мне очень нравит- 
ся этот колоритный термин.) Можно было бы объявить и передавать име- 
нованный объект: 


РорЁез$ сотр; 
ѕогі( ѕіаеѕ, ѕіаїеѕ+50, сотр ); 


Однако удобнее просто передавать анонимный временный объект. 


Положительный эффект применения объекта-функции в качестве компа- 
ратора в том, что сравнение будет подставлено в строку, тогда как в слу- 
чае применения указателя на функцию этого сделать нельзя. Преимуще- 
ство встраиваемого вызова заключается в следующем: при создании эк- 
земпляра шаблона функции компилятору известен тип компаратора (Рор- 
[е55), что, в свою очередь, дает ему информацию о будущем вызове 
Роріеѕѕ: :орегаїог () и обеспечивает возможность встроить эту функцию, 
используя встраиваемый вложенный вызов роріеѕѕ. 


Еще один распространенный случай применения объектов-функций ТІ, — 
использование в качестве предикатов. Предикат — это логическая опера- 
ция в отношении одного объекта. (Компаратор можно рассматривать как 
разновидность бинарного предиката.) 


ѕігисі ТзМагт : рир1іс зіа: :ипагу Рипстіоп<Ѕ+ате, роо1> { 
роо1 орега+ог ()( сопѕї Ѕате &а ) сопѕї 
{ гефигп а. ауеТетрЕ() > 60; } 
}; 


Рекомендации по разработке предикатов ТІ, аналогичны рекомендаци- 
ям по компараторам БТТ,, за исключением того, конечно, что предикаты 
БТІ, представляют собой унарные, а не бинарные функции. Основываясь 
на полученных ранее результатах сортировки Ѕїаїе, с помощью соответ- 
ствующих предикатов нетрудно найти теплое неперенаселенное местеч- 
ко: 


ЭТафе *магтапаѕрагѕе = Ріпа і#?( ѕтаеѕ, ѕіаіеѕ+50, ІѕМагт() ); 


Тема 21 | Перегрузка и переопределение - 
это не одно и то же 


У перегрузки и переопределения нет ничего общего. Ничего. Непонима- 
ние этой разницы или небрежное отношение к терминам привели к нево- 
образимой путанице и стали причиной несметного количества ошибок. 


Перегрузка имеет место, когда в одной области видимости есть две или 
более функции с одинаковыми именами и разными сигнатурами. Сигна- 
тура функции состоит из количества и типа объявленных параметров (их 
еще называют формальными параметрами). Найдя в области видимости 
несколько функций с одинаковыми именами, компилятор выбирает из 
них лишь одну, формальные параметры которой больше всего соответст- 
вуют фактическим параметрам вызова функции (см. также темы 24 «По- 
иск функции-члена» и 25 «Поиск, зависимый от типов аргументов»). 
Вот это и есть перегрузка. 


Переопределение имеет место, когда имя и сигнатура функции производ- 
ного класса полностью совпадают с виртуальной функцией базового клас- 
са. В этом случае для виртуальных вызовов производного объекта реали- 
зация функции производного класса заместит функцию, унаследованную 
от базового класса. Переопределение меняет поведение класса, но не его 
интерфейс (но см. тему 31 «Ковариантные возвращаемые типы»). 


Рассмотрим следующий простой базовый класс: 


с1а55 В { 
рир11с: 
И 
У1гЕиа1 1пЕ #( іп ); 
уоіа #( В = ); 
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Уря 
}; 


Имя # перегружено в В, потому что в одной области видимости находятся 
две функции с именем Г. (Перегрузка выделена как плохой код по двум 
причинам. Вероятно, не стоит перегружать виртуальную функцию и, воз- 
можно, не следует перегружать функции и с целочисленным типом, и сти- 
пом указателя. Обратитесь к книгам [2] и [5] соответственно, чтобы по- 
нять почему.) 


с1аѕѕ 0 : рир1іс В { 
рир1іс: 
іпі #( іп ); 
іп #СВ = ); 
| 


Функция-член 0: : (111) переопределяет виртуальную функцию базового 
класса В::#(іпі). Функция-член 0::#(В *) ничего не переопределяет, пото- 
му что В::#(В *) не является виртуальной. Однако она перегружает 
0::#(іп). Обратите внимание, что эта функция не перегружает члены ба- 
зового класса В: :, потому что они находятся в другой области видимости 
(см. тему 63 «Необязательные ключевые слова»). 


Перегрузка и переопределение — разные концепции. Формальное пони- 
мание их разницы исключительно важно для тех, кто хочет глубоко раз- 
бираться в углубленных аспектах проектирования интерфейсов базовых 
классов. 


Тема 22 | Шаблонный метод 


Шаблонный метод (Тешр|афе Ме од) не имеет ничего общего с шаблона- 
ми С++. Скорее это средство, с помощью которого проектировщик базово- 
го класса может дать четкие инструкции по реализации контракта базо- 
вого класса проектировщикам производных классов (см. тему 2 «Поли- 
морфизм»). Однако даже если вам кажется, что этот паттерн должен быть 
назван иначе, пожалуйста, придерживайтесь стандартного названия 
«Шаблонный метод». Одним из главных преимуществ использования 
паттернов является вводимый ими стандартный словарь технических 
терминов (см. тему 3 «Паттерны проектирования»). 


Базовый класс определяет контракт с внешним миром преимущественно 
посредством своих открытых функций-членов. Дополнительные детали 
для производных классов описываются защищенными функциями-чле- 
нами. Закрытые функции-члены тоже могут использоваться как часть ре- 
ализации класса (см. тему 12 «Присваивание и инициализация – это не 
одно и то же»). Данные-члены должны быть закрытыми, поэтому оста- 
вим их за рамками данного обсуждения. 


Решение по поводу того, какой должна быть функция-член базового 
класса – виртуальной, невиртуальной или чисто виртуальной, — вытека- 
ет главным образом из того, как будет реализовываться поведение этой 
функции в производном классе. Ведь коду, использующему интерфейс 
базового класса, на самом деле все равно, как объект реализует конкрет- 
ную операцию. Он хочет осуществлять эту операцию, а уж объекту ре- 
шать, как правильно реализовать ее. 


Если функция-член базового класса невиртуальная, проектировщик ба- 
зового класса определяет инвариант иерархии базового класса. Произ- 
водные классы не должны скрывать невиртуальную функцию базового 
класса за своими членами с таким же именем (см. тему 24 «Поиск функ- 
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ции-члена»). Если контракт, определенный базовым классом, не подхо- 
дит, необходимо искать другой базовый класс. Нельзя пытаться перепи- 
сать этот контракт. 


Виртуальные и чисто виртуальные функции определяют операции, реа- 
лизации которых могут быть настроены производными классами посред- 
ством переопределения. Функция, не являющаяся чисто виртуальной, 
предоставляет реализацию по умолчанию и не требует переопределения, 
тогда как чисто виртуальная функция должна быть переопределена в кон- 
кретном (т. е. не абстрактном) производном классе. Оба вида виртуальной 
функции позволяют производному классу полностью заменять свою реа- 
лизацию, сохраняя интерфейс. 


Применение шаблонного метода обеспечивает проектировщику базового 
класса промежуточный уровень контроля между «используй ее или ос- 
тавь ее в покое» для невиртуальной функции и «если не нравится, замени 
все» для виртуальной функции. Шаблонный метод фиксирует общую 
структуру реализации, но некоторую ее часть адресует производным клас- 
сам. Обычно Шаблонный метод реализован как открытая невиртуальная 
функция, вызывающая защищенные виртуальные функции. Производ- 
ный класс должен принимать общую реализацию, определенную в уна- 
следованной невиртуальной функции базового класса, но может настро- 
ить ее поведение ограниченным числом способов, переопределяя защи- 
щенные виртуальные функции, которые она инициирует. 


с1аѕѕ Арр { 
рир11с: 
уігіџа1 ?Арр(); 
Е 


уоіа ѕіагіир() { // Шаблонный метод 
111 1а117е(); 
1Е( !ма11дате() ) 
а1+1пії(); 
} 
рготестеа: 
уігіџа1 6001 ма1ідате() сопѕї = 0; 
уігіџа1 у019 а1+1пії() 
ы 
ргімаїе: 
үоіа іпіїіа1іхе() 
ГЕ 
}; 


Невиртуальный Шаблонный метод ѕїагіир вызывает функции, настроен- 
ные производными классами: 
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с1аѕѕ МуАрр : руб11с Арр { 
рир11с: 
Е 
ргімаїе: 
роо1 уа1іда+е() сопѕ+; 
уоіа а1+11пії(); 
нч 
}; 


Шаблонный метод – это пример принципа Голливуда в действии: «Не 
звоните нам, мы сами вам позвоним» (см. тему 19 «Команды и Голли- 
вуд»). Поток выполнения функции ѕіагіир определяется базовым клас- 
сом. Функция ѕіагіир, в свою очередь, вызывается клиентами интерфей- 
са базового класса. Проектировщики производных классов не знают, ко- 
гда будут вызваны функции уа1ійаїе или а111пії. Но им известно, что 
должны делать уа1ідаїе и а111пії, когда будут вызваны. Совместно базо- 
вый и производные классы обеспечивают полную реализацию функции. 


Тема 23 | Пространства имен 


Глобальная область видимости была переполнена. Все кому не лень реа- 
лизовывали библиотеки, использующие одни и те же имена для разных 
классов и функций. Например, многие библиотеки желали включить 
класс с именем 5{г1пд, но если использовать две разные библиотеки, опре- 
деляющие тип 5{г1п9, возникает ошибка многократного определения или 
что-нибудь похуже. Различные дополнительные подходы к решению 
этой проблемы (соглашения о присваивании имен, препроцессор и дру- 
гие) только ухудшали ситуацию. На помощь пришли пространства имен. 


В каком-то смысле пространства имен вводят дополнительную сложность 
(см. тему 25 «Поиск, зависимый от типов аргументов»), но в большин- 
стве своем упрощают дело и работать с ними не очень трудно. Простран- 
ство имен — это подраздел глобальной области видимости: 


патезрасе огд_зетап{1с$ { 
с1аѕѕ Ѕігіпод {... }; 
5г1пд орегатог +( сопзф Ѕїгіпо &, сопѕї Ѕїігіпо & ) 
// другие классы, функции, объявления типов и т.д.. 


} 


В данном фрагменте кода пространство имен огд_зетап{1с$ открывается, 
объявляется несколько полезных функций и затем пространство имен за- 
крывается фигурной скобкой. Всегда можно что-то добавить в простран- 
ство имен, просто повторив эту операцию. Пространства имен являются 
«открытыми». 


Обратите внимание, что некоторые имена пространства имен огд_зетап- 
їісѕ объявлены, но не описаны. Чтобы описать эти имена, можно повтор- 
но открыть пространство имен: 


патезрасе ого_ѕетапіісѕ { 
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Ѕігіпо орега+ог +( сопзЕ Ѕігіпо ёа, 5%г1пд &6 ) { // ой 
Е 


} 


В качестве альтернативы можно просто уточнить описание именем про- 
странства имен без повторного открытия пространства имен: 


ога_зетап{1с$: : 57119 

ого _ѕетапіісѕ: : орегафог +( 
сопзЕ огд_зетап{1с$::5{г1пд ёа, 
сопѕі огд_зетап{1с$::5г1п9 &6 ) { 
е е 

} 


Преимущество такого подхода в том, что он не позволяет по неосторожно- 
сти объявить новое имя пространства имен (как мы сделали, когда не 
включили сопзі во втором аргументе первого определения орегаїог+). На- 
до сказать, это бесконечное повторение огд_зетап{1с$ в данном случае мо- 
жет быть утомительным, но такова цена безопасности! Мы обсудим неко- 
торые подходы, которые могут несколько улучшить ситуацию. 


Если необходимо использовать имя, описанное в определенном простран- 
стве имен, надо сообщить компилятору, в каком пространстве имен мож- 
но его найти: 


ого_зетап1с$::5г1п9 $( "Не110, Мог1а!” ); 


Хотя часть стандартной библиотеки С++ осталась в глобальном простран- 
стве имен (на ум приходят стандартные глобальные операторы орегаїог 
пем, орегатог де1ете, орега+ог пем[] и орега+ог де1еїе[ ] для создания и унич- 
тожения массивов), основной ее состав теперь находится в пространстве 
имен $14 (от збапагА – стандартное). В большинстве случаев использова- 
ние стандартной библиотеки требует указания имени пространства имен 
ѕ1а: 


#іпс1иџде <іоѕігеат> 
#1пс1иае <уесїіог> 


Ире 

№019 аРипс() { 
уесіог<іпі> а; // ошибка! Я не вижу вектора! 
$14: :уесТог<іпї> 0; // 0, вот он 


сои << "00рѕ!” << епа; // ошибки! 


ЗЕ: :соиф << "Веїтег!" << ѕїа: :епаї1; // ОК 
у 
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Очевидно, что необходимость постоянного явного указания имени про- 
странства имен утомляет. Избежать этого позволяет директива 15119. 


уоіа аРипс() { 


и$1п9 патезрасе $19; // директива и$1п9 
уесіог<іпї> а; // ОК 

соиї << "Не110!" << еп@1; // ОК 

//... 


} 


Директива и$1п0 («используется») по сути «импортирует» имена из про- 
странства имен, делая их доступными без квалификации в области види- 
мости директивы џѕіпо. В данном случае директива џѕіпд действует до 
конца тела функции, а затем необходимо опять возвращаться к явной 
квалификации. По этой причине многие программисты на С++ (даже те, 
кому «виднее») предлагают помещать директиву иѕіпо в глобальную об- 
ласть видимости: 


#1іпс1иде <іоѕігеат> 

#1пс1иае <уесїіог> 

иѕіпо патеѕрасе $19 

иѕіпо патеѕрасе ого ѕетаптісѕ 


Это неудачная идея. Получается, что мы вернулись практически к тому, 
с чего начали: все имена пространства имен доступны везде, сея путаницу 
и неразбериху. Это особенно нежелательно в заголовочном файле, по- 
скольку неудачное решение распространяется на все файлы, включаю- 
щие данный заголовочный файл. В заголовочных файлах, как правило, 
лучше явно указывать квалификаторы, а директивы и$1п9 приберечь для 
меньших областей видимости (таких как тела функций или блоки в рам- 
ках функции), где их действие ограничено и легче контролируется. По су- 
ти, в заголовочных файлах необходимо строго следовать правилам, в фай- 
лах реализации — выполнять рекомендации, а внутри функции можно 
расслабиться. 


Один любопытный аспект директив и$1п0 — имена пространства имен ста- 
новятся доступными, как будто они объявлены глобально, а не в той об- 
ласти видимости, в которой используется директива иѕіпо. Локальные 
имена перекрывают имена пространства имен: 


уоіа аРипс() { 
иѕіпо патеѕрасе $19; // директива иѕіпо 


ИИ 
іп уесїог = 12; // неудачное имя для локальной переменной. .. 
уесїог<іпї> а; // ошибка! 51а: :уесїог скрыт 


ѕа::уесіог<іпі> 0; // ОК, можно использовать явную квалификацию 


У аа 
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} 


В качестве альтернативы можно назвать объявление иѕіпо (иѕіпе Аес1ага- 
Ноп), обеспечивающее доступ к имени пространства имен через фактиче- 
ское объявление: 


уоіа ағипс() { 
иѕіпо 51а: :уес+ог; // из1п9-объявление 


Е 

іп месїог = 12; // ошибка! Повторное объявление уесїог 
уесїіог<іпі> а; // ОК 

Е 


} 


Џѕіпо-объявления зачастую представляют собой золотую середину между 
утомительными явными квалификациями и избыточным применением 
директив и$1п9, особенно если если в разделе кода используется лишь па- 
ра имен из двух или более пространств, но зато неоднократно: 


№019 аҒипс() { 
иѕіпо 51: : Сои; 
иѕіпо 51а: :епа1; 
иѕіпо огд_зетап{1с$: :5їгіпо; 
гіпо а, 0, с; 
Ис 


соиї << а << р << с << етот; 


// ит.д. 
} 


Другой способ борьбы с длинными утомительными именами пространств 
имен состоит в применении псевдонимов: 


патезрасе 5 = огд_зетапт1с$; 


Теперь 5 может использоваться в области видимости псевдонима вместо 
огд_зетап{1с$. Как и в случае директивы иѕіпо, лучше избегать примене- 
ния псевдонимов пространств имен в заголовочных файлах. (Кроме всего 
прочего, 5, скорее всего, будет конфликтовать с другими именами намно- 
го чаще, чем огд_зетап{1с$...) 


Завершим краткий обзор пространств имен рассмотрением анонимных 
пространств имен: 


папеѕрасе { 
іпї апіпі = 12; 
іп аРипс() { гефигп апІпі; } 
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Поведение этого анонимного пространства имен аналогично следующему, 
где _ сотр11ег_депегафед_пате__ («сгенерированное компилятором имя») 
уникально для каждого анонимного пространства имен: 


патезрасе __сотрі1ег_депегатеа пате __ { 
іпї апіпі = 12; 
іп аРипс() { гефигп апіп; } 

} 


иѕіпод патеѕрасе 


_сотрі1ег депега+еа пате __; 


Это самый передовой способ избежать объявления функций и перемен- 
ных со статическим связыванием. В приведенном выше анонимном про- 
странстве имен обе функции – апіпі и ағипс — имеют внешнее связывание, 
но доступ к ним может быть осуществлен только в рамках единицы 
трансляции (т. е. в полученном после предварительной обработки файле), 
в которой они находятся, точно так же, как к статическим переменным. 


Тема 24 | Поиск функции-члена 


Вызов функции-члена включает три этапа. Сначала компилятор ищет 
имя функции. Затем из доступных кандидатов он выбирает наиболее под- 
ходящую функцию. Далее он проверяет, имеет ли вызывающий доступ 
к выбранной функции. Вот и все. Надо сказать, каждый из этих этапов 
(особенно первые два; см. темы 25 «Поиск, зависимый от типов аргумен- 
тов» и 26 «Поиск операторной функции») может быть сложным, но ме- 
ханизм сопоставления функций в целом предельно прост. 


Большинство ошибок, связанных с сопоставлением функций, происхо- 
дит не от незнания сложного механизма поиска имени компилятором 
и алгоритмов сопоставления перегруженных функций, а от непонимания 
простой последовательной природы этапов сопоставления. Рассмотрим 
следующий фрагмент кода: 


с1а55 В { 
рир11с: 
н 
\01а #( доџр1е ); 
}; 
с1аѕѕ 0 : рир1іс В { 
моіа #( іп? ); 
}; 
Пн 
ра; 
а. #( 12.3 ); // сбивает с толку 


Какой член вызывается? 


Шаг 1: Ведем поиск имени функции. Поскольку вызывается член объек- 
та 0, поиск начинается в области видимости 0. Сразу же обнаруживается 
ВЕ: 
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Шаг 2: Из доступных кандидатов выбираем наиболее подходящую функ- 
цию. В данном случае имеется только один кандидат, 0::#, поэтому пыта- 
емся сопоставить его. Это можно сделать путем преобразования фактиче- 
ского аргумента 12.3 из йоџр1е в іпї. (Это допустимо, но, как правило, не- 
желательно, поскольку теряется точность.) 


Шаг 3: Проверяем возможность доступа. Может возникнуть ошибка, по- 
тому что 0::# – закрытый. 


Наличие более подходящей доступной функции в базовом классе не име- 
ет значения, потому что компилятор, обнаружив функцию во внутренней 
области видимости, не продолжает поиск имени во внешних областях ви- 
димости. Имя из внутренней области видимости скрывает такое же имя 
во внешней области. Такой перегрузки, как в Јауа, не происходит. 


На самом деле даже необязательно, чтобы имя было именем функции: 


с1а5 Е : рир1іс р { 
ТП Г; 

}; 

Иа 

Ее; 

е.Г( 12 ); // ошибка! 


В данном случае возникает ошибка компиляции, потому что поиск имени 
Т в области видимости приводит к члену данных, а не функции-члену. 
Это, кстати, одна из основных причин, по которой следует установить 
и соблюдать простое соглашение о присваивании имен. Если бы член дан- 
ных Е: :Г имел имя Г_ или п_Р, он бы не скрыл унаследованную функцию 
базового класса Г. 


Тема 25 | Поиск, зависимый от типов 
аргументов 


Пространства имен имеют огромное влияние на современные программы 
и проекты С++ (см. тему 23 «Пространства имен»). Отчасти это влияние 
очевидно, например в наличии объявлений и директив и$1п9 и квалифи- 
каторов имен. Однако пространства имен оказывают и менее заметное 
с точки зрения синтаксиса, но не менее фундаментальное и важное влия- 
ние. Сюда относится поиск, зависимый от типов аргументов (Агэитеп% 
дерепаеп+ Іоокир, Ар). Как и многие другие возможности С++, АПТ, по- 
тенциально сложен, но в обычной работе он прост и решает больше про- 
блем, чем создает. 


Идея, лежащая в основе АПГ, проста. При поиске имени функции, ука- 
занного в выражении вызова функции, компилятор также будет прове- 
рять пространства имен, содержащие типы аргументов вызова функции. 
Рассмотрим следующий код: 


патезрасе огд_зетап{1с$ { 
С1а$$ Х {... }; 
уоіа #( сопѕї Х & ); 
№019 9( Х * ); 
Х орегатог +( сопѕї Х &, сопѕЇі Х & ); 
с1аѕѕ Ѕігіпод 4... }; 
ѕіа::оѕігеат орегафог <<( ѕїа: :оѕїгеат &, сопѕї Ѕігіпо & ); 
} 
И 
11 9( ого _ѕетапі1с::Х * ) 
№019 аРипс() { 
ога _ѕетапіісѕ: :Х а; 
#( а ); // вызываем ого _ѕетапїіс:: # 
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9( ва ); // ошибка! неоднозначность. .. 
а = а+а; // вызываем огд_зетап{1с$: : орегафог + 


} 


Обычный поиск не выявит функции 0г0_ѕетапіісѕ: :#, потому что она вло- 
жена в пространство имен и перед Г не указан квалификатор пространст- 
ва имен. Однако тип аргумента а определен в пространстве имен огд_зе- 
тап{1с$, поэтому компилятор ведет поиск подходящих функций и в нем. 


Конечно, такое сложное правило, как АПГ,, может неоднократно заста- 
вить программиста «почесать затылок». Вызов д с указателем на огд_зе- 
папїтісѕ::Х — именно такой случай. Здесь программист, наверное, полага- 
ет, что компилятор обнаружит глобальную 9. Но поскольку фактический 
аргумент относится к типу ого ѕепапїісѕ: :Х *, при поиске были включены 
ди из этого пространства имен, и вызов стал неоднозначным. Поразмыс- 
лив, можно сказать, что на самом деле эта неоднозначность не так страш- 
на, потому что, скорее всего, программист намеревался вызвать функцию 
огд_зетап{1с$: :9, а не ::9. Выявив неоднозначность, программист может 
или устранить ее, или переименовать одну из функций. 


Обратите внимание, что, хотя при вызове д в результате обнаруживаются 
две функции-кандидата на разрешение перегрузки, ::9 не перегружает 
огд_зетап{1с$: :9, потому что они объявлены в разных областях видимости 
(см. тему 21 «Перегрузка и переопределение – это не одно и то же»). 
АПТ, – это особенность вызова функции, а перегрузка — особенность ее 
объявления. 


Реальную пользу от применения АРІ, можно увидеть при работе с ин- 
фиксными вызовами перегруженных операторов, например при исполь- 
зовании орегаїог + в аРипс. Здесь инфиксное выражение а+а эквивалентно 
вызову орегаїог +(а, а), и Ар, обнаружит перегруженный орегаїог+ в про- 
странстве имен ого ѕепапіісѕ (см. также тему 26 «Поиск операторной 
функции»). 


На самом деле большинство программистов на С++ активно применяют 
АТГ, даже не осознавая этого. Рассмотрим следующее обычное примене- 
ние <іоѕігеат>: 


огд.ѕзетапііс: :Ѕігіпо паме( "Омап” ); // ОМАМ - Оџа13 ум Еһпоџ+АМате, качество без 
ѕіа: :сои << "Не110, " << пате; // без названия, не поддающееся формулировке 


В данном случае первый (самый левый) вызов орегаїог<<, по всей вероят- 
ности, представляет собой вызов функции-члена шаблона класса $14: :ра- 
$1с_оз{геат, тогда как второй — это вызов функции-нечлена перегружен- 
ной функции орегатог<< пространства имен ого_ѕепапїісѕ. Такие подробно- 
сти на самом деле совершенно неинтересны автору приветствия, а АПІ, 
справляется со всем этим просто замечательно. 


Тема 26 | Поиск операторной функции 


Иногда все выглядит так, как будто операторная функция-член перегру- 
жает оператор-нечлен. Но это не так. Это не перегрузка, а просто другой 
алгоритм поиска. Рассмотрим следующий класс, перегружающий опера- 
тор как функцию-член: 


с1а55 Х { 
рир11с: 
Х орегафог %( сопѕї Х & ) сопѕї; // бинарный оператор нахождения модуля 
Х тетРипс1( сопѕі Х & ); 
\01а петЕипс2(); 
Е 
}; 


Перегруженную операторную функцию можно вызвать или как инфикс- 
ный оператор, или с помощью синтаксиса вызова функции: 


Ха, б, с; 

а= р % с; // инфиксный вызов оператора-члена % 
а = 5. орегафог %( с ); // вызов функции-члена 

а = 0. тетРипс1( с ); // вызов другой функции-члена 


Синтаксис вызова функции активизирует обычные правила поиска (см. 
тему 24 «Поиск функции-члена») и вызов р.орегаїог %(с) интерпретирует- 
ся так же, как и аналогичный вызов пепЕипс1. Однако инфиксный вызов 
перегруженного оператора обрабатывается иначе: 


Х орегафог %( сопѕі Х &, іпі ); // оператор-нечлен 


Ирена 
уоіа Х: : тетРипс2() { 
хїһіѕ % 12; // вызывает оператор-нечлен % 


орегафог %( *{п1з, 12 ); // ошибка! слишком много аргументов 
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Для вызова инфиксного оператора компилятор рассмотрит обе функции, 
и член и нечлен (см. также тему 25 «Поиск, зависимый от типов аргу- 
ментов»). Таким образом, первый инфиксный вызов орегаїог % будет со- 
ответствовать нечлену. Это не экземпляр перегрузки, просто компилятор 
проводит поиск функций в двух разных местах. Далее неинфиксный вы- 
зов подчиняется стандартным правилам поиска функций и выявляет 
функцию-член. Мы получили ошибку, потому что пытались передать три 
аргумента в бинарную функцию. (Вспомните неявный аргумент {11$ для 
функций-членов!) 


В сущности инфиксные вызовы перегруженных операторов реализуют 
своего рода «вырожденный» АПТ, в котором при выборе функции, ис- 
пользуемой для разрешения перегрузки, учитываются и класс левого 
(или единственного) аргумента инфиксного оператора, и глобальная об- 
ласть видимости. АРІ, расширяет этот процесс операторными функция- 
ми других пространств имен, внесенных аргументами оператора. Обрати- 
те внимание, что это не перегрузка. Перегрузка - это статическое свойст- 
во объявления функции (см. тему 21 «Перегрузка и переопределение — 
это не одно и то же»). И АПТ, и поиск инфиксного оператора - это свой- 
ства аргументов вызова функции. 


Тема 27 | запросы возможностей 


В большинстве случаев используемый объект способен выполнять все, что 
от него требуется, потому что его возможности явно проанонсированы вего 
интерфейсе. В таких случаях мы не спрашиваем объект, может ли он сде- 
лать ту или иную работу; мы просто приказываем ему приступить к ней: 


с1а55 Ѕһаре { 
рир1іс: 
уігіџа1 ?Ѕһаре(); 
үігіџа1 у019 Чгам() сопѕі = 0; 


Деян 
}; 
з 
Ѕһаре *з = деЅотеѕ$һаре(); // прими фигуру и скажи ей... 
ѕ->дгам(); //...за работу! 


Конечно, мы не знаем точно, с каким типом фигуры имеем дело, но зна- 
ем, что это Ѕһареи, следовательно, может отрисовать себя. Так все и обсто- 
ит, просто и рационально, а нам того и надо. 


Однако жизнь не всегда настолько проста. Иногда возможности объекта 
не столь очевидны. Пусть, например, необходима фигура, которая может 
катиться: 


с1аѕѕ Во11ар1е { 
рир11с: 
уігіџа1 7Во11ар2е(); 
уігіџа1 уо1іа го11() = 0; 
}; 


Такие классы, как Ао11ар1е (то, что можно катать), часто называют ин- 
терфейсными классами, потому что они определяют только интерфейс, 
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подобно Јауа-интерфейсу. Обычно у таких классов нет нестатических 
членов данных, нет объявленного конструктора, есть виртуальный дест- 
руктор и набор чисто виртуальных функций, которые определяют, что 
может делать объект Во11а 1е. В данном случае говорится: все, что явля- 
ется ВЌо11ар1е, может катиться; все остальное не может: 


с1аѕѕ Сігс1е : рир1іс Зпаре, риб11с Во11ар1е { // круги могут катиться 
Иа 
үоіа агам() сопзі; 
уоіа г011(); 


аты 
}; 
с1аѕѕ бацаге : рир1іс Ѕһаре { // квадраты не могут 
Е 
уоіа агам() сопзі; 
Е 


}; 
Конечно, кроме фигур, могут катиться и другие объекты: 
с1аѕѕ Мһее1 : рир1іс Во11ар1е {... }; 


В идеале код должен быть организован таким образом, чтобы еще до по- 
пыток вращения (применения метода г011()) всегда было известно, отно- 
сится ли объект к классу Но11а01е – как раньше мы знали, что имеем дело 
с объектом типа Ѕһаре до попытки отрисовать его. 


уестог<Во11аб]е *> го111поЅїоск; 


Т 
Тог( уестог<Во11ар1е *>::ііегаог 1( го11іпозіоск. редіп() ); 
1 1= го11іподЅїоск.епа(); ++і ) 
(х1) ->г011(); 


К сожалению, время от времени возникают ситуации, когда просто неиз- 
вестно, обладает ли объект требуемой возможностью. В таких случаях 
приходится осуществлять запрос возможностей. В С++ запрос возможно- 
стей обычно представляется в виде дупат1с_саз{ (динамическое приведе- 
ние) между несвязанными типами (см. тему 9 «Новые операторы приве- 
дения»). 


Ѕһаре *з = деїЅотеЅһаре(); 
Во1]аб]е *го11ег = дупатіс_саѕі<Ћо11ар1е *>(3); 


Этот вид Чупат1с_саз{ часто называют перекрестным приведением (сгозз- 
саѕі), потому что здесь происходит превращение на одном уровне иерар- 
хии, а не вверх или вниз по ней (рис. 27.1). 


Если $ ссылается на Ѕдиаге, йупатіс_саѕї даст сбой (будет получен нулевой 
указатель), а значит, тип Ѕһаре, на который ссылается $, не является Во] - 
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Относится ли Ѕһаре к классу Во11аб1е? 


ү 


оваре Во]1а]е 
Л 
5диаге Сігс1е 


Рис. 27.1. Запрос возможности: «Эту фигуру можно катить?» 


1ар1е. Если $ ссылается на Сігс1е или любой другой тип Ѕһаре, производ- 
ный от Во11ар1е, приведение пройдет успешно, и мы будем знать, что мо- 
жем вращать эту фигуру. 


Ѕһаре *з = деїЅотеЅһаре(); 
1Е( Во11ар1е *го11ег = дупатіс_саѕі<Ћо11ар1е *>($) ) 
го11ег->г011(); 


Необходимость в запросах возможностей время от времени возникает, но 
часто ими злоупотребляют. Обычно они являются индикатором плохого 
проектирования. Если доступны другие рациональные подходы, лучше 
избегать применения запросов времени выполнения о возможностях объ- 
ектов. 


Тема 28 | Смысл сравнения указателей 


В С++ у объекта может быть несколько действительных адресов. Сравне- 
ние указателей на объекты - это не вопрос об адресах. Это вопрос об иден- 
тичности объектов. 


с1аѕѕ Ѕһаре {... }; 
с1аѕѕ Ѕирјесї {... }; 
с1аѕѕ ОбѕегуедвВ1ор : рир1іс Ѕһаре, рир1іс Ѕџирјесї { ... }; 


В приведенной иерархии 0056гуе0В10р является производным и от Эпаре, 
и от 5и6] ест, и (поскольку наследование открытое) существуют предопре- 
деленные преобразования из 065егуедВ10 в любой из его базовых классов. 


ОбзегмиедВ1о6 *об = пем ОбзегуедВТо6; 
Ѕһаре *5 = ор; // предопределенное преобразование 
Ѕирјесі *з3и6] = об; // предопределенное преобразование 


Доступность этих преобразований означает, что указатель на 00ѕегуедв1ор 
можно сравнивать с указателем на любой из его базовых классов. 


і?( ор == $ ) ... 
іР?( ѕирј == ор ) 


В данном случае оба эти условия будут истинными, даже если адреса, со- 
держащиеся в ор, ѕ и ѕирј, разные. Рассмотрим два возможных размеще- 
ния в памяти объекта 00ѕегуеВ1ор, на который ссылаются эти указатели 
(рис. 28.1). 


При первом размещении $ и ѕирј ссылаются на подобъекты Зпаре и Ѕирјесї 
полного объекта, адреса которых отличаются от адреса полного объекта, 
на который ссылается ор. При втором размещении подобъект Эпаре имеет 
тот же адрес, что и полный объект ОбѕегуеВ1ор, таким образом, ор и $ со- 
держат один и тот же адрес. 
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Рис. 28.1. Два возможных размещения объекта при множественном 
наследовании. При любом размещении объект имеет несколько адресов 


При любом размещении ор, $ и ѕзирј ссылаются на один и тот же объект 00- 
ѕегуейВ1ор, поэтому компилятор должен убедиться, что ор идентичен и 5, 
и ѕирј. (Нельзя сравнивать $ с ѕирј, потому что между ними нет отноше- 
ния наследования.) Это сравнение компилятор осуществляет путем до- 
полнения значения одного из сравниваемых указателей соответствую- 
щим смещением. Например, выражение 


06 == ѕирј 
может быть интерпретировано (вольно) так: 
ор ? (о6+де]{а == ѕи0ј) : ($и6] == 0) 


где де1Та — смещение подобъекта Ѕирјесї в ОбѕегуейВ1ор. Другими слова- 
ми, ори $16] равны, если обе они нулевые; в противном случае ор настраи- 
вается, чтобы ссылаться на подобъект базового класса Ѕирјесі, и затем 
сравнивается с $16]. 


Из этих рассуждений необходимо извлечь один важный урок: при работе 
с указателями и ссылками на объекты (да и вообще всегда) необходимо 
быть осторожными, чтобы не потерять информацию о типе. Указатели на 
\014 — обычные виновники этой потери: 


№019 *\ = $и6]; 
і?( ор == у ) // не равны! 


Как только содержащийся в ѕирј адрес оказался лишенным информации 
о своем типе из-за копирования в \014 *, компилятору не остается ничего 
другого, как только прибегнуть к простому сравнению адресов. Для ука- 
зателей на объекты классов это приемлемо далеко не всегда. 


Тема 29 | Виртуальные конструкторы 
и Прототип 


Представьте, что вы сидите в шведском ресторане и хотите сделать заказ. 
К несчастью, ваше знание шведского ограничено технической докумен- 
тацией, ругательствами или (как правило) комбинацией одного и друго- 
го. Меню написано на шведском, читать на котором вы не умеете. Однако 
в другом конце комнаты вы замечаете джентльмена, наслаждающегося 
своим кушаньем. Поэтому вы подзываете официанта и говорите: 


«Если тот джентльмен ест рыбу, я бы хотел рыбу. Если он ест спа- 
гетти, я тоже хочу спагетти. Если же он ест угря, пусть будет 
угорь. Даже если он остановился на консервированных кумкватах, 
то и мне дайте того же». 


Разве это звучит разумно? Конечно, нет. (Так, например, вряд ли следует 
заказывать спагетти в шведском ресторане.) В данной ситуации можно 
обозначить две основные проблемы. Во-первых, этот метод утомителен 
и неэффективен. Во-вторых, он может не сработать. А если, закончив 
свою речь, вы так и не угадаете, что ест другой посетитель? Официант уй- 
дет, оставив вас в затруднительном положении и голодным. Даже если 
вам каким-то чудом удалось узнать все меню и поэтому успех (в конечном 
счете) гарантирован, список вопросов может оказаться недействитель- 
ным или неполным - ведь меню могли изменить в промежутке между ва- 
шими посещениями ресторана. 


Правильно было бы, конечно, просто подозвать официанта и сказать: 
«Я бы хотел то, что ест тот джентльмен». 


Если официант привык все понимать буквально, он выхватит наполови- 
ну съеденное блюдо у другого посетителя и принесет его вам. Однако та- 
кое поведение может обидеть и даже привести к конфликту. Подобные 
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недоразумения происходят, когда два посетителя пытаются взять одно 
и то же блюдо одновременно. Если официант знает свое дело, он принесет 
вам точную копию блюда, поглощаемого другим клиентом, никак не влияя 
на состояние копируемого блюда. 


Мы проиллюстрировали два основных мотива клонирования, которые 
можно сформулировать так: вы не обязаны знать точный тип объекта, 
с которым имеете дело, и не хотите изменять исходный объект или зави- 
сеть от его изменений. 


Функцию-член, предоставляющую возможность клонирования объекта, 
в С++ традиционно называют виртуальным конструктором. Конечно, 
виртуальных конструкторов не существует, но при создании копии объек- 
та обычно осуществляется непрямой вызов конструктора копий класса 
через виртуальную функцию, что создает эффект – если не реальность — 
виртуального конструктора. В последнее время эту технику называют эк- 
земпляром паттерна Прототип (Ртоїо+уре). 


Конечно, надо хоть что-то знать об объекте, на который осуществляется 
ссылка. В данном случае известно, что нам нужна еда (теа!]). 


с1аѕѕ Меа1 { 
рир1іс: 
уігіџа1 Меа1(); 
үуігіџа1 уоіа ваї() = 0 
\1гЕиа1 Меа1 *с10пе() сопѕі = 0; 
//... 
}; 


Тип Меа1 обеспечивает возможность клонирования с помощью функции- 
члена с1опе. Функция с1опе представляет собой специализированную раз- 
новидность Фабричного метода (см. тему 30 «Фабричный метод»), кото- 
рая создает соответствующий продукт, при этом обеспечивая возмож- 
ность инициирующему коду оставаться в неведении о точном типе кон- 
текста и классе продукта. Конкретные классы, производные от Меа1 (те 
блюда, которые фактически существуют и перечислены в меню), должны 
предоставлять реализацию чисто виртуальной операции клонирования. 


с1аѕѕ браднете1 : рир1іс Меа1 { 
рир11с: 
Ѕрадһеї+і( сопѕї Ѕрадћеіті & ); // конструктор копий 
уоіа еаї(); 
Ѕрадһеїіі *с1опе() сопѕї 
{ гефигп пем Ѕраоћеї+і( «+һіѕ ); } // вызов конструктора копий 
у 
}; 
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(Почему возвращаемый тип переопределяющей функции с10опе производ- 
ного класса отличается от возвращаемого типа функции базового класса, 
объясняется в теме 31 «Ковариантные возвращаемые типы».) 


С помощью этого простого каркаса можно создавать копии любого типа 
Меа1, не зная точно фактического типа копируемого Меа1. Обратите внима- 
ние, что в следующем коде нет никакого упоминания о конкретных про- 
изводных классах и, следовательно, нет привязки кода к какому-либо те- 
кущему или будущему производному от Ма1 типу. 


сопѕі Меа] хп = їһаібиуѕМеа1(); // что бы это ни было... 
Меа] *туМеа1 = т->с10пе(); //...я тоже хочу это! 


Фактически можно дойти до того, чтобы заказывать то, о чем никогда да- 
же не слышал. Благодаря использованию паттерна Прототип незнание 
о существовании типа не мешает создать объект этого типа. Приведенный 
выше полиморфный код может быть откомпилирован, распределен 
и в дальнейшем пополнен новыми типами Меа1 без необходимости повтор- 
ной компиляции. 


Этот пример иллюстрирует некоторые преимущества неведения при про- 
ектировании программного обеспечения, в частности, структурированно- 
го как каркас, предназначенный для настройки и расширения. Чем мень- 
ше знаешь, тем лучше. 


Тема 30 | Фабричный метод 


Высокоуровневое проектирование часто требует создания объекта «соот- 
ветствующего» типа на основании типа существующего объекта. Напри- 
мер, имеется указатель или ссылка на объект Етр1оуее (Служащий) какого- 
то типа. Необходимо сгенерировать соответствующий для этого типа Еп- 
р1оуее объект НАТпто (Сведения о ресурсе), как показано на рис. 30.1. 


Етр1оуее НВІпТО 


Ѕа1агу Ноиг1у Тетр огаїп?о Тетр1п#о 


Рис. 30.1. Псевдопараллельные иерархии. Как проецируется служащий 
на соответствующую информацию о трудовых ресурсах? 


Здесь иерархии Етр1оуее и НАІп#о практически параллельны. Служащим ти- 
па Ѕа1агу (Оклад) и Ноиг1у (Почасовая оплата) требуются объекты типа 519- 
Тито, тогда как служащим типа Тетр (Временный) требуется объект Тепрїп#о. 


Идея высокоуровневого проектирования проста: необходимо создать со- 
ответствующий тип записи для этого служащего. К сожалению, програм- 
мисты нередко считают, что это оправдывает использование запросов 
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о типе во время выполнения. То есть код, реализующий это требование, 
определяет тип генерируемого объекта НАТпТо, задавая вопросы о точном 
типе Етр1оуее. 


Использование кода типа служащего и инструкции зм11с! — распростра- 
ненный и всегда ошибочный подход: 


с1азз Етр1оуее { 
рир11с: 
епит Туре { ЅАГАВҮ, НООАІҮ, ТЕМР }; 
Туре +уре() сопѕї { гефигп уре; } 
аат 
ргіуаїе: 
Туре Туре _; 
Иа 
В 
И: 
НАТпРо *депТпРо( сопѕї ЕтрТоуее &е ) { 
эміїсһ( е. ?уре() ) { 
саѕе ЅАГАВҮ: 
сазе НОЦВІҮ: гефигп пем Ѕ+аТпҒо( е ); 
саѕе ТЕМР: гефигп пем ТетрІпғҒо( ѕаіс саѕі<сопѕі Тетр *>(е) ); 
деғаи11ї: гефигп 0; // код неизвестного типа! 
} 
} 


Ничем не лучше использование дупат1с_саз{ для задания серии личных 
вопросов об объекте Етр1оуее: 


НАТпРо *депТпРо( сопѕї ЕтрТоуее &е ) { 

1Р( сопѕі За]1агу *з = дупатіс саѕзі<сопѕї Ѕа1агу *>(&е) ) 
геигп пем 5101пғо( ѕ ); 

6156 і?( сопѕї Ноиг1у *һ = дупатіс саѕї<сопѕї Ноџг1у *>(&е) ) 
геигп пем ЭТаТпто( п ) 

е1зе і?( сопѕі Тетр *ї = дупатіс саѕі<сопѕї Тетр *>(&е) ) 
геигп пем ТетрТиРо( т ); 

е1 зе 
геїигп 0; // неизвестный тип служащего 


} 


Основная ошибка в обеих приведенных реализациях депіпѓо в том, что 
они связаны с конкретными производными от Епр1оуее и НАТпРо типами 
и должны уметь проецировать служащих всех типов в соответствующие 
типы НАТпРо. Любые изменения в множестве типов Етр1оуее, НАТпТРо или 
в проецировании одного в другое требуют изменения кода. Скорее всего 
новые типы в этих иерархиях будут добавляться (или удаляться) посто- 
янно; маловероятно, что изменения в коде всегда будут осуществляться 
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правильно. Другая проблема — при любом подходе может произойти 
ошибка в определении точного типа аргумента Епр10уее. При этом потребу- 
ется организовать обработку этой ошибки в коде, вызывающем деп1ТпТо(). 


Верный подход состоит в том, чтобы рассмотреть, где должна находиться 
проекция из любого типа Епр1оуее на соответствующий тип НАІпѓо. Иначе 
говоря, кто лучше всего знает, какой тип объекта НВІпѓо нужен служаще- 
му типа Тептр? Конечно, сам служащий Тептр: 


с1аѕѕ Тетр : рир1іс Етр1оуее { 
рир1іс: 
Е 


ТетрТпРо *депіпғо() соп 
{ гефигп пем ТетрТиРо( *«+һ1ѕ ); } 


ЕВ 
}; 


По-прежнему остается нерешенной проблема, связанная с тем, что может 
быть неизвестен тип служащих, с которыми мы имеем дело. Но это легко 
исправить с помощью виртуальной функции: 


с1аѕѕ Етр1оуее { 
рир1іс: 
П а 


уігіџа1 НАТпРо *депТпРо() сопѕі = 0; // Фабричный метод 


//... 
}; 


Это экземпляр паттерна Фабричный метод (Ғасіогу Ме Тод). Вместо мас- 
сы глупых личных вопросов, по сути, служащему говорят: «Какого бы 
типа ты ни был, генерируй для себя соответствующий тип информации». 


Етр1оуее *е = детАпЕтр1оуее(); 
У 


НАТиРо *х1пРо = е->депІп#о(); // используется Фабричный метод 


Суть Фабричного метода в том, что базовый класс предоставляет вирту- 
альную функцию-ловушку для генерирования соответствующего «про- 
дукта». Каждый производный класс может переопределить эту унаследо- 
ванную виртуальную функцию, чтобы генерировать собственный про- 
дукт. В результате получаем возможность использования объекта неиз- 
вестного типа («некоторый тип служащих») для генерирования объекта 
неизвестного типа («соответствующий тип информации»). 


Обычно о необходимости применения Фабричного метода при высоко- 
уровневом проектировании свидетельствует потребность генерировать 
«соответствующий» объект на основании конкретного типа другого объ- 
екта, параллельные или почти параллельные иерархии. Часто этот пат- 
терн является лекарством от серии запросов о типе на этапе выполнения. 


Тема 31 | Ковариантные возвращаемые типы 


Как правило, возвращаемый тип переопределяющей функции должен 
быть таким же, как иу функции, которую она переопределяет: 


с1аѕѕ Ѕһаре { 
рир11с: 
Иа 
үігїџа1 доџир1е агеа() сопѕї = 0; 
ать 
|: 
с1аѕѕ Сігс1е : рир1іс Ѕһаре { 
рир11с: 
Ғ1оаї агеа() сопзт; // ошибка! другой возвращаемый тип 


//... 


}; 


Однако для так называемых ковариантных возвращаемых типов это 
правило не настолько строгое. Если В — тип класса, и виртуальная функ- 
ция базового класса возвращает В *, переопределяющая функция произ- 
водного класса может возвращать 0 х, где 0 — открыто наследуется от В. 
(То есть р представляет собой В.) Если виртуальная функция базового 
класса возвращает В &, переопределяющая функция производного класса 
может возвращать 0 &. Рассмотрим следующую операцию клонирования 
в иерархии фигур (класса Ѕһаре) (см. тему 29 «Виртуальные конструкто- 
ры и Прототип»): 


с1аѕѕ Ѕһаре { 
рир11с: 
И 
уігіџа1 Ѕһаре *с1опе() сопѕі = 0; // Прототип 


Иан 
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с1аѕѕ Сігс1е : рир1іс Ѕһаре { 
рир11с: 
Сігс1е *с10пе() соп5ї; 


а 
}; 


Объявлено, что переопределяющая функция производного класса возвра- 
щает Сігс1е *, а не Ѕһаре *. Это допустимо, потому что Сігс1е представляет 
собой Ѕһаре. Обратите внимание, что возвращаемое из Сігс1е: :с1опе значе- 
ние (ігс1е * автоматически преобразуется в Варе *, если С1гс1е интерпре- 
тируется как Ѕһаре (см. тему 28 «Смысл сравнения указателей»): 


Ѕһаре *51 = детАСігс1е0гО+һегЅһаре(); 
Ѕһаре *52 = 51->с10пе(); 


Преимущество применения ковариантных возвращаемых типов стано- 
вится очевидным при работе с производными типами напрямую, а не че- 
рез интерфейсы их базового класса: 


Сігс1е *с1 = де+АСігс1е() 
Сігс1е *с2 = с1->с10пе(); 


Без ковариантного возвращаемого типа Сігс1е::с1опе должен был бы точ- 
но совпадать с возвращаемым типом Ѕћһаре: :с1опе и возвращать опаре *. 
Пришлось бы приводить возвращаемый результат к Сігс1е *. 


Сігс1е *с1 = детАС1гс1е() 
Сігс1е *с2 = ѕТаїіс саѕї<Сігс1е *>(с1->с1опе()); 


В качестве другого примера рассмотрим следующий член Ѕһаре, относя- 
щийся к Фабричному методу, который возвращает ссылку на соответст- 
вующий редактор конкретной фигуры (см. тему 30 «Фабричный метод»): 


с1аѕѕ ЅһареЕаіїог {... }; 
с1аѕѕ Ѕһаре { 
рир11с: 
Уа 
уігіџа1 сопѕї ЅһареЕаіТог & 
детЕаііог() сопзф = 0; // Фабричный метод 


Иа 
}; 
Ин 
с1а55 С1гс1е; 
с1аѕѕ Сігс1еЕді+ог : рир1іс ЅһареЕді+ог {... }; 
с1аѕѕ Сігс1е : рир1іс Ѕһаре { 
рир1іс: 


сопе Сігс1еЕаді+ог &де+Едітог() сопѕі; 
ТЕ 
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В данном случае обратите внимание, что Сігс1еЕйіїог должен быть полно- 
стью определен (не просто объявлен) до объявления Сігс1е: :оеїЕдіїог. 
Компилятор должен знать устройство объекта Сігс16Е0іїог, чтобы иметь 
возможность осуществлять соответствующие манипуляции с адресом для 
преобразования ссылки (или указателя) на Сігс1еЕйіїог в ссылку (или 
указатель) на ЅһареЕіїог. (См. тему 28 «Смысл сравнения указателей».) 


Преимущество ковариантного возвращаемого типа в том, что всегда мож- 
но работать на соответствующем уровне абстракции. Если работаепть 
с объектами Ѕһаре, получаешь абстрактный ЅһареЕйіїог; работая с опреде- 
ленным типом фигуры, например С1гс1е, можешь иметь дело напрямую 
с Сігс1еЕаітог. Ковариантный возвращаемый тип освобождает от необхо- 
димости применять приведение (так чреватое ошибками) для допоставки 
информации о типе, которая ни в коем случае не должна быть утеряна: 


Ѕһаре *з = де+АСігс1е0г0+ћегЅһаре(); 
сопзЕ ЅһареЕаіїог &зе9 = 5->деїЕаі+ог(); 
Сігс1е *с = детАС1гс1е(); 

сопѕЁ Сігс1іеЕді+ог &сед = с->детЕд1Тог(); 


Тема 32 | Предотвращение копирования 


Спецификаторы доступа (риб11с, ргоїесїей и ргіуаїе) могут применяться 
для выражения и реализации высокоуровневых ограничений на исполь- 
зование типа. Чаще всего для этого запрещают копировать объект. Опе- 
рации копирования объекта объявляются закрытыми и не определяются: 
с1аѕѕ № бору { 
рир11с: 
МоСору( іп ); 
И 
рг1\ате: 
МоСору( сопзЕ №Сору & ); // конструктор копий 
МоСору &орегафог =( сопзі №Сору & ); // копирующее присваивание 
}; 


Конструктор копий и оператор копирующего присваивания должны быть 
обязательно объявлены, поскольку в противном случае компилятор объ- 
явит их неявно как открытые подставляемые в строку члены. Объявле- 
ние их закрытыми предотвращает вмешательство компилятора и гаран- 
тирует, что любое использование этих операций – явное или неявное — 
приведет к ошибке компиляции: 


уоіа аРипс( М№оСору ); 

уоіа апоїћегРипс( сопѕі М№Сору & ); 

МоСору а( 12 ); 

№оСору 0( а ); // ошибка! конструктор копий 

№оСору с = 12; // ошибка! неявный конструктор копий 


а = (0 // ошибка! копирующее присваивание 
ағипс( а ); // ошибка! передача по значению с помощью конструктора копий 
аРипс( 12 ); // ошибка! неявный конструктор копий 


апоёћегЕипс( а ); // ОК, передача по ссылке 
апоћегЕипс( 12 ); // ОК 


Тема 33 | Как сделать базовый класс 
абстрактным 


Абстрактные базовые классы обычно представляют абстрактные концеп- 
ции предметной области, поэтому нет смысла объявлять объекты этих ти- 
пов. Абстрактным базовый класс можно сделать, объявив (или унаследо- 
вав) по крайней мере одну чисто виртуальную функцию. Тогда компиля- 
тор гарантирует невозможность создания объекта абстрактного базового 
класса. 


с1аѕѕ АВС { 
рир11с: 
үуігіџа1 -АВС(); 
уігіџа1 уоід ап0регатіоп() = 0; // чисто виртуальная 
н 
| 


Однако иногда подходящего кандидата на чисто виртуальную функцию 
нет, но необходимо, чтобы класс вел себя как абстрактный базовый. В этих 
случаях приблизиться к природе абстрактности можно, убрав из класса 
все открытые конструкторы. Это неизменно означает необходимость яв- 
ного объявления по крайней мере одного конструктора, поскольку в про- 
тивном случае компилятор неявно объявит открытый подставляемый 
конструктор по умолчанию. Компилятор также объявит неявный кон- 
структор копий (если он не объявлен явно), поэтому обычно приходится 
объявлять два конструктора. 


с1аѕѕ АВС { 
рир1іс: 
үуігіџа1 -АВС(); 
рготестеа: 
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АВС(); 
АВС( сопѕї АВС & ); 
Ре 

}; 

С1аз$ 0 : рир1іс АВС { 
Е 

|. 


Конструкторы объявляются защищенными, чем обеспечивается возмож- 
ность их использования конструкторами производных классов, но пре- 
дотвращается создание отдельных объектов АВС. 


\019 Рипс1( АВС ); 
уоіа Гипс2( АВС & ); 


АВС а; // ошибка! защищенный конструктор по умолчанию 
ра; // ОК 

#Ғипс1( а ); // ошибка! защищенный конструктор копий 

#ипс2( а ); // ОК, нет конструктора копий 


Другой способ сделать класс абстрактным базовым — назначить одну из 
его виртуальных функций чисто виртуальной. Обычно для этого отлично 
подходит деструктор: 


с1аѕѕ АВС { 
рир11с: 
уігїџа1 -АВС() = 0; 
ан 
}; 
Дал 
АВС: :-АВС() {... } 


Заметьте, что в данном случае необходимо предоставить реализацию чис- 
то виртуальной функции, поскольку деструкторы производных классов 
будут вызывать деструкторы своего базового класса неявно. (Обратите 
внимание, что этот неявный вызов деструктора базового класса из дест- 
руктора производного класса всегда является невиртуальным.) 


Третий подход применяется, когда у класса вообще нет виртуальных 
функций и нет необходимости явного объявления конструкторов. В этом 
случае целесообразно создать защищенный невиртуальный деструктор. 


с1аѕѕ АВС { 
рготестеа: 
-АВС(); 
рир1іс: 
Ио 
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Эффект от применения защищенного деструктора практически такой же, 
как и от защищенного конструктора, но ошибка возникает не при созда- 
нии объекта, а когда объект выходит за рамки области видимости или яв- 
но уничтожается: 


уоіа ѕотеЕипс() { 


АВС а; // ошибки пока нет. . 
АВС *р = пем АВС; // ошибки пока нет. . 
//... 


ае1ете р; // ошибка! защищенный деструктор 
// ошибка! неявный вызов деструктора а 


Тема 34 | Ограничение на размещение 
в куче 


Иногда требуется показать, что объекты определенного класса не долж- 
ны размещаться в куче (пеар). Часто это делается для того, чтобы гаран- 
тировать вызов деструктора объекта, как в случае с объектом «вап Ме» 
(дескриптор), реализующим подсчет ссылок для объекта «роду» (тело). 
Деструкторы локальных объектов классов с автоматическим распределе- 
нием памяти будут вызываться автоматически, кроме случаев аварийно- 
го прерывания программы с помощью функций ехії (выход) или абог{ 
(преждевременное прекращение). То же самое происходит и с объектами 
статически создаваемых классов (кроме выхода по функции арогі), тогда 
как динамически создаваемые объекты должны уничтожаться явно. 


Обозначить такое предпочтение можно через запрещение выделения па- 
мяти в куче: 


с1а55 МоНеар { 
рир1іс: 
а 
рготестеа: 
үоіа *орега+ог пем( 317е_+ ) { гефит 0; } 
уоіа орегаїог ае1еїе( \уо19 * ) {} 
}; 


Любая стандартная попытка размещения объекта №Неар в куче приведет 
к ошибке компиляции (см. тему 36 «Индивидуальное управление памя- 
тью»): 


МоНеар *пћ = пем М№оНеар; // ошибка! защищенный МоНеар: : орегафог пем 


ИИ... 


Че1ете пп; // ошибка! защищенный М№оНеар: : орегафог де1еїе 
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Члены орегаїог пем и орегафог йе1еїе определены (и объявлены), потому 
что на некоторых платформах конструкторы и деструкторы могут вызы- 
вать их неявно. По той же причине они объявляются защищенными: они 
могут быть инициированы неявно конструкторами и деструкторами про- 
изводных классов. Если №Неар не предполагается использовать как базо- 
вый класс, эти функции можно объявить закрытыми. 


В то же время может понадобиться уделить внимание размещению масси- 
вов объектов №Неар (см. тему 87 «Создание массивов»). В этом случае дос- 
таточно объявить функции создания и уничтожения массива закрытыми 
и неопределенными, аналогично тому, как налагается запрет на опера- 
ции копирования (см. тему 32 «Предотвращение копирования»). 


с1а55 МоНеар { 
рир1іс: 
Е 
рготестеа: 
№019 *орегафог пем( $17е_+ ) { гефит 0; } 
\019 орегаїог ае1ете( \уо19 * ) {} 
ргіхаїе: 
үоіа *орега+ог пем[ ]( ѕіғе ї ) 
\019 орегаїог ае1ете[ ]( уоіа * ); 
}; 


Кроме того, можно содействовать размещению в куче, а не запрещать его. 
Просто делаем деструктор закрытым: 


с1аѕѕ ОпНеар { 
-ОпНеар(); 
рир1іс: 
үоіа деѕїгоу() 
{ деЈеїе 1һіѕ; } 
ч 
}; 


Любое обычное объявление объекта с автоматическим распределением 
памяти или статически создаваемого объекта ОпНеар приводит к неявному 
вызову деструктора, когда имя объекта выходит за рамки области види- 
мости. 


ОпНеар оһћ1; // ошибка! неявный вызов закрытого деструктора 
№019 аРипс() { 

ОпНеар оћ2; 

е. 


// ошибка! неявный вызов деструктора для оћ2 


Тема 35 | синтаксис размещения пез 


Вызвать конструктор напрямую невозможно. Однако с помощью синтак- 
сиса размещения пем можно обмануть компилятор и заставить его вызы- 
вать конструктор. 


уоіа *орегаог пем( ѕіге 1, уоіа *р ) +һгом() 
4 геїигп р; } 


Синтаксис размещения пен — это стандартная глобальная перегруженная 
версия орегаїог пем, которая не может быть замещена пользовательской 
версией (в отличие от стандартных глобальных «обычных» орегаїог пем 
и орегафог де1еїе, которые могут замещаться, но это не рекомендуется). 
Реализация игнорирует аргумент размера и возвращает второй аргумент. 
Тем самым разрешается «размещать» объект в определенном месте, что 
обеспечивает эффект возможности вызова конструктора. 


с1аѕѕ ЅРогі { ... }; // представляет последовательный порт 
сопѕі іпїі соміос = 0х00400000, // местоположение порта 
еы 


уоіа *сопАайг = геіптегргеї_саѕї<уо1іа *>(сотіос); 
ЅРогі *соті = пем (сотАдаг) Рогі; // создается объект по адресу сотіос 


Важно отличать оператор пем от функций под именем орегаїог пем. Опера- 
тор пем не может быть перегружен и, таким образом, всегда ведет себя 
одинаково: вызывает функцию орегаїог пем и инициализирует возвращае- 
мую область памяти. Все варианты поведения при распределении памяти 
обеспечиваются разными перегруженными версиями орегаїог пем, ане 
оператором пем. То же самое можно сказать и об операторе де1ете и функ- 
ции орегаїог де1еїе. 


Синтаксис размещения пен — разновидность функции орегаїог пем, кото- 
рая на самом деле не выделяет память. Она лишь возвращает указатель 


Синтаксис размещения пем/ 121 


на хранилище, которое (предположительно) уже существует. Поскольку 
при вызове синтаксиса размещения пем память не выделяется, важно не 
удалить его. 


де1ефе сот1; // ой! 


Однако, хотя память и не была выделена, объект был создан, и этот объ- 
ект должен быть уничтожен по окончании его времени жизни. Мы избе- 
гаем оператора де1ете и вместо него вызываем прямо деструктор объекта: 


сот1->-9Рогї(); // вызывается деструктор, а не оператор де1ете 


Однако часто прямые вызовы деструкторов сопровождаются ошибками, 
в результате чего либо один и тот же объект уничтожается многократно, 
либо объект не уничтожается вовсе. Такие конструкции лучше приме- 
нять только в случае необходимости в хорошо скрытых и правильно ис- 
пользуемых областях кода. 


Также существует синтаксис размещения массива, позволяющий созда- 
вать массив объектов в заданном местоположении: 


Ссоп5ї іпі питСотѕ = 4; 


//... 


ЭРогЕ *сотРогіѕ = пем (сотАдаг) эРогЕ[питСомз]; // создается массив 
Конечно, эти элементы массива в конце концов должны быть уничтожены: 


ТИ 1 = пимСомз$; 
мһі1е( і ) 
сотРогїѕ[--і 1. ~$Рогї(); 


Для массивов объектов класса характерна одна проблема – при размеще- 
нии массива каждый элемент должен быть инициализирован вызовом 
конструктора по умолчанию. Рассмотрим простой буфер фиксированного 
размера, в который может быть добавлено новое значение: 


ѕігіпо *збиЁ = пем зЕгіпоГВОЕІ2Е]; // вызывается конструктор по умолчанию 
// для всех элементов массива! 


ТЕ 51і7е = 0; 
уоіа аррепа( ѕїгіпо би?[ ], іпї &$17е, сопѕї ѕігіпо ёуа1 ) 
{ риғ[517е++] = уа1; } // уничтожает инициализацию по умолчанию! 


Если используется только часть массива или если элементам немедленно 
присваиваются значения, это решение неэффективно. Еще хуже, если 
тип элементов массива не имеет конструктора по умолчанию. Тогда мы 
получим ошибку компиляции. 


Синтаксис размещения пем часто применяется для решения этой пробле- 
мы с буфером. При таком подходе хранилище для буфера выделяется та- 
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ким образом, чтобы избежать инициализации конструктором по умолча- 
нию (если таковой существует). 


сопѕї 317е_{ п = 51і7ео#(ѕігіпо) * ВУЕЗТИЕ; 
ѕігіпо *збиР = ѕіатіс саѕі<ѕігіпо *>(::орегафог пем( п )); 
ТИПЕ 5і7е = 0; 


Нельзя осуществить присваивание при первом обращении к элементу 
массива, потому что он еще не был инициализирован (см. тему 12 «При- 
сваивание и инициализация – это не одно и то же»). Поэтому для ини- 
циализации элемента конструктором копий применяется синтаксис раз- 
мещения пем: 


уоіа аррепа( ѕїгіпо ри? ], ілі &ѕіхе, сопзі ѕігіпо &уа1 ) 
{ пем (&ри?[512е++]) зігіпо( уа1 ); } // синтаксис размещения пем 


Как обычно, при использовании синтаксиса размещения пеп требуется 
провести очистку ресурсов самостоятельно: 


уоіа с1еапирВит( эїгіпо Бы[], іпї $17е ) { 
мһі1е( 317е ) 
ри?[--ѕ1і7е]. 7=1гіпод(); // уничтожаем инициализированные элементы 
::орегатог де1ете( би? ); // высвобождаем хранилище 
} 


Данный подход быстр, разумен и не предназначен для широкой публики. 
Описанная базовая методика широко применяется (в более сложной фор- 
ме) в большинстве реализаций контейнеров стандартной библиотеки. 


Тема 36 | Индивидуальное 
управление памятью 


Стандартные функции орегаїог пем и орегаїог де1ете не всегда обрабатыва- 
ют типы классов так, как нам надо. Но у типов могут быть собственные 
функции орегаїог пем и орегаїог де1ете, соответствующие их нуждам. 


Мы ничего не можем сделать с операторами пем или ае1ете, потому что их 
поведение неизменно, но можно изменить вызываемые ими функции оре- 
гафог пем и орега+ог де1ете (см. тему 35 «Синтаксис размещения пеш»). 
Лучше всего объявить функции-члены орегаїог пем и орегаїог де1ете: 


с1аѕѕ Напа1е { 
рир1іс: 
СЕ 
үоіа *орега+ог пем( ѕіхө_ї ); 
уоіа орегаїог ае1ете( уоіа * ) 


ы 
}; 
Иры 
Напа]е *П = пем Напа]е; // используем Нап16: : орегафог пем 
И 
де1ете п; // используем Напа1е: :орегафог де1ете 


При размещении в памяти объекта типа Напа1е в выражении пем компиля- 
тор сначала поищет орегаїог пем в области видимости Напд1е. Если член оре- 
гаїог пем не будет найден, компилятор использует глобальный орегаїог пем. 
Аналогична ситуация и для орегаїог йе1еїе, поэтому обычно имеет смысл 
определять член орегаїог йе1е+е, если определяется орегаїог пем, и наоборот. 


Члены орегаїог пем и орегаїог йе1еїе представляют собой статические 
функции-члены (см. тему 63 «Необязательные ключевые слова»), что 
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оправданно. Вспомним, что у статических функций-членов нет указателя 
1ћіѕ. Они отвечают только за получение и высвобождение хранилища для 
объекта, поэтому им не нужен указатель 1115. Как и другие функции-чле- 
ны, они наследуются производными классами: 


с1аѕѕ МуНапа1е : рир1іс Напа1е { 


а 
}; 
Иа 
МуНапа1е «тп = пем МуНапа]1е; // используется Напа]е: :орегафог пем 
И 
де1ете тһ; // используется Напа1е: : орегафог йе1ете 


Конечно, если бы МуНапа1е объявил собственные орегаїог пем и орегаїог ае- 
Іеїе, компилятор находил бы их первыми при поиске, и они бы использо - 
вались вместо унаследованных от базового класса Нап1е версий. 


При определении членов орегаїог пем и орегаїог де1ете в базовом классе де- 
структор класса должен быть гарантированно виртуальным: 


с1аѕѕ Напа1е { 
рир1іс: 
Е 
уігіџа1 -Напа1е(); 
үоіа *орега+ог пем( ѕіхө_ї ); 
\019 орегаїог ае1ете( уоіа * ) 
ны 
}; 
с1аѕѕ МуНапа1е : рир1іс Напа1е { 
в 
үоіа *орега+ог пем( ѕіхе + ); 
уоіа орегафог де1ете( уоіа *, $17е т ); // обратите внимание 
// на 2-й аргумент 


Иры 
у; 
а 
Напа1е *П = пем МуНапа1е; // используется МуНапа1е: :орегатог пем 
ть 
де1ете п; // используется МуНапд1е: :орегафог де1ете 


Без виртуального деструктора эффект от удаления объекта производного 
класса через указатель на базовый класс непредсказуем! Реализация мо- 
жет (и, вероятно, неправильно) инициировать Напа]е : :орегаїог ае1ете, а не 
МуНапа16 : :орегаїог де1ете. Вообще случиться может все, что угодно. Также 
обратите внимание, что здесь реализован двухаргументный вариант орега- 
їог де1ете, а не обычный одноаргументный. Двухаргументная версия пред- 
ставляет собой еще одну «обычную» версию члена орегаїог де1ете. Ее часто 
используют базовые классы, для которых предполагается наследование 
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производными классами их реализации орегаїог йе1еіе. Второй аргумент 
будет содержать размер удаляемого объекта. Эта информация часто ока- 
зывается полезной при реализации обычного распределения памяти. 


Широко распространено заблуждение, что применение операторов пем 
и 0е16їе подразумевает необходимость работать с кучей (ћеар), или свобод- 
ной памятью. Вызов оператора пен лишь означает, что будет вызвана функ- 
ция орегаїог пем и эта функция возвратит указатель на некоторую область 
памяти. Стандартные глобальные орегафог пем и орегафог де1ефе действи- 
тельно распределяют память из кучи, но члены орегаїог пем и орегатог йе- 
1еїе могут делать все, что угодно. Нет ограничения на то, где будет выделе- 
на область памяти. Она может поступить из специальной кучи, из статиче- 
ски выделенного блока, из недр стандартного контейнера или из блока ло- 
кальной памяти функции. Единственным ограничением в данном случае 
являются изобретательность разработчика и здравый смысл. Например, 
объекты Напд1е могли бы быть размещены в таком статическом блоке: 


ѕігисі гер { 
епит { тах = 1000 }; 


ѕ+аїіс гер *Ргее; // начало статического блока 
ѕаііс іпі пит _џиѕеа; // число используемых слотов 
ипіоп { 
сһаг ѕіоге[ ѕіғео#(Напа1е) ]; 
гер *пехі; 
}; 
}; 
ѕіа+іс гер мет[ гер: :тах ]; // блок статического хранилища 
уоіа *Напа1е: :орегаог пем( ѕіғе ї ) { 
1Р( гер: :#гее ) { // если есть слоты в списке Тгее 
гер *їтр = гер: : Егее; // берем объект из списка Ёгее 
гер: :Тгее = гер: : Ғгее->пехї; 
гефигп тр; 
} 
е1ѕе 1{( гер::пит_изеа < гер::тах ) // если остались слоты 
гефигп &тет[ гер::пит_изед++ ]; // вернуть неиспользованный слот 


е1ѕе // в противном случае, ... 
їһгом 514: : раа _а110с(); // ...нехватка памяти! 
} 
уоіа Напа1е: :орегафог де1еїе( м019 *р ) { // добавить в список Ргее 
ѕ+аїіс_саѕі<гер *>(р)->пехї = гер: :#гее; 
гер::Егее = ѕїаїіс саѕї<гер *>(р); 
} 


Промышленная версия была бы более строгой относительно условий не- 
хватки памяти при работе с производными от Напд]1е типами, массивами 
объектов Напа] е и т. д. Тем не менее этот код демонстрирует, что операто- 
рам пем и де1ете необязательно работать с кучей. 


Тема 37 | Создание массивов 


Большинство программистов на С++ знают, что необходимо строго при- 
держиваться установленного синтаксиса для массивов и немассивов при 
выделении и высвобождении памяти. 


Т хат = пем Т; // немассив 

Т *агут = пем Т[12]; // массив 

де1еїе [] агут; // массив 

ае1еїе ат; // немассив 

ат = пем Т[1]; // массив 

Че1ете ат; // ошибка! должен быть массив 


Очень важно применять эти пары функций правильно, потому что при 
выделении и высвобождении памяти под массивы применяются совер- 
шенно другие функции, чем для немассивов. Для выделения памяти под 
создаваемый массив применяется не орегаїог пем, а его версия для масси- 
ва. Аналогично для высвобождения памяти, занятой массивом, вызыва- 
ется не орегаїог де1ете, а его версия для массива. Точнее, при выделении 
памяти под массив используется один оператор (пем[ ]), а при распределе- 
нии памяти под немассив – другой (пен). То же самое происходит при вы- 
свобождении памяти. 


Функции создания и уничтожения массивов — это аналоги функций ор- 
егатог пем и орегаїог йе1еїе. Объявляются они аналогично: 


\014 *орегатог пем( $12е + ) їһгом( раа а110ос ); // орегатог пем 

уоіа *орегаїог пем[ ]( ѕіхе і ) +һгом( раа а110ос ); // версия пем для массива 
уоіа орегафог де1еїе( уоіа * ) +һгом(); // орегатог де1е+е 

уоіа орегаїог де1еїе[ 1( моіа * ) Егом(); // версия е1еїе для массива 


Чаще всего путаница с формами этих функций для массивов возникает, 
когда отдельный класс или иерархия определяет собственное распределе- 
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ние памяти с помощью членов орегаіог пем и орегаїог де1ете (см. тему 36 
«Индивидуальное управление памятью»). 


с1а55 Напа1е { 
рир1іс: 
И р 
үоіа *орега+ог пем( ѕіхө_ї ); 
уоіа орегаїог ае1еїе( уоіа * ) 
а 
}; 


Класс Напд1е определил функции распределения памяти для немассивов. 
Для массива объектов Напд1е будут вызваны не они, а глобальные функ- 
ции создания и уничтожения массива: 


Напае *һапа1еЅеі = пем Напа1е[МАХ]; // вызывается ::орегафог пем[] 


//... 


Че1ете [] һапд1е$еї; // вызывается ::орегафог деЈеїе[ ] 


Может показаться, что логично всегда объявлять эти функции в форме 
для массивов, даже для немассивов (хотя странно, что это не обычная 
практика). Если цель действительно состоит в вызове глобальных опера- 
ций создания массива, было бы правильней, если бы локальные формы 
операторов просто делегировали такой вызов: 


с1аѕѕ Напа1е { 
рир1іс: 
зав 
үоіа *орега+ог пем( ѕіхө_ї ); 
уоіа орегаїог ае1ете( уоіа * ) 
үоіа *орега+ог пем[ ]( ѕіғе ї п ) 
{ геигп ::орегафог пем( п); } 
уоіа орегаїог ае1еїе[ ]( уоіа *р ) 
4 ::орегафог де1еїе( р ); } 


//... 


); 


Если же надо препятствовать созданию массивов объектов Напй1е, тогда 
формы для массивов можно объявить закрытыми и оставить без опреде- 
ления (см. тему 34 «Ограничение на размещение в куче»). 


Второй источник неразберихи и ошибок связан со значением аргумента 
размера, который передается в функцию создания массива в зависимости 
от того, как вызывается функция. Когда орегаїог пен вызывается (неявно) 
в выражении создания, компилятор определяет необходимый объем па- 
мяти и передает это значение как первый аргумент орегаїог пем. Это раз- 
мер создаваемого объекта: 


ат = пем Т; // вызывается орегафог пем( ѕіғео#(Т) ); 
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Также функция орегаїог пен может быть вызвана напрямую. В этом слу- 
чае требуемое количество байтов надо задать явно: 


ат = ѕіаїіс саѕі<Т *>(орегатог пем( ѕіғео#(тТ) )); 
Можно также напрямую вызвать версию орегаїог пем для массива: 
агут = ѕїаїіс саѕі<Т *>(орегаїог пем[ 1( 5 * ѕіғео?(Т) )); 


Однако при неявном вызове версии орегаїог пем для массива через выра- 
жение создания компилятор может немного увеличить запрашиваемое 
число байтов, и часто он именно так и поступает: 


агут = пем Т[5]; // запрашивается 5 * $17е0(Т) + смещение 


Дополнительный объем памяти обычно используется диспетчером рабо- 
чей памяти для записи информации о массиве, которая позже необходима 
для восстановления памяти (число размещенных элементов, размер каж- 
дого элемента и т. д.). Сложности возникают из-за того, что компилятор 
может запрашивать это дополнительное пространство не при каждом рас- 
пределении памяти, и размер запроса может меняться от случая к случаю. 


Настраивать запрашиваемый объем памяти обычно можно только в очень 
низкоуровневом коде, который размещает массивы напрямую. Если вы 
собираетесь заниматься разработкой кода нижнего уровня, то проще избе- 
гать прямых вызовов версии оре гатог пем для массива и связанных с этим 
действий компилятора и использовать старую добрую функцию орегаїог 
пем (см. тему 35 «Синтаксис размещения пеш»). 


Тема 38 | Аксиомы надежности исключений 


Написание надежной! программы немного напоминает доказательство 
теоремы евклидовой геометрии. Сначала с помощью минимального набо- 
ра аксиом доказываются простые теоремы. Затем эти вспомогательные 
теоремы служат для доказательства более сложных полезных теорем. 
С надежностью то же самое. Надежный код создается из надежных ком- 
понентов. (Хотя любопытно отметить, что лишь композиция ряда надеж- 
ных компонентов или вызовов функций не гарантирует, что результат бу- 
дет надежным. Это было бы слишком просто, не правда ли?) Как в любой 
системе доказательств, здесь необходимо полагаться на ряд аксиом, с по- 
мощью которых создается наша надежная структура. Что это за аксио- 
мы? 


Аксиома 1: исключения синхронны 


Во-первых, необходимо обратить внимание на то, что исключения син- 
хронны и могут возникать только на границе вызова функции. Поэтому 
арифметические действия над предопределенными типами, присваива- 
ние предопределенных типов (особенно указателей) и другие низкоуров- 
невые операции не приведут к возникновению исключения. (В результа- 
те их выполнения мог бы возникнуть сигнал или прерывание некоторого 
рода, но это не исключения.) 


Перегрузка операторов и шаблоны усложняют ситуацию, поскольку час- 
то трудно определить, приведет ли выполнение той или иной операции 
к вызову функции и потенциальному исключению. Например, я знаю, 


1 Речь идет о надежности в случае возникновения исключительной ситуации 
(Ехсеріїоп ѕаѓеѓу). – Примеч. перев. 
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что исключение не возникнет, если происходит присваивание символь- 
ных указателей, тогда как в случае присваивания пользовательских 
строк (51г1п9) это возможно: 


сопзЕ сһаг ға, *р 

бїгіпо с, Я; 

е 

а = б; // нет вызова функции, нет исключения 
с = д; // вызов функции, возможно исключение 


В случае применения шаблонов неопределенность возрастает: 


тетр1ате <+урепате Т> 
уоіа атТетр1атеСоп+іехї() { 


Те, Г; 

Т +0, *П: 

ИИ 

е = Г; // вызов функции? исключение? 

9 =; // нет вызова функции, нет исключения 
ИИ 


} 


Из-за этой неопределенности необходимо принять, что все потенциаль- 
ные вызовы функций в рамках шаблона представляют собой вызовы 
функций. Это касается инфиксных операторов, неявных преобразований 
ит. д. 


Аксиома 2: уничтожать безопасно 


Эта аксиома скорее социальная, чем техническая. Условно деструкторы, 
орегаїог де1етїе и орегаїог йе1еїе[], не формируют исключений. Рассмот- 
рим воображаемый деструктор, который должен удалять два указателя 
на данные-члены. Мы знаем, что подвергнемся критике, гонениям и изо- 
ляции, если позволим исключению сформироваться в деструкторе, поэто- 
му задействуем блок {гу: 


Х::-Х() 4 

гу { 
де1ете ріг1_ 
де1іете рїг2_; 


} 
Сатоћ( „а 34} 
} 


Этот стиль отнюдь не обязателен, но угроза неодобрения окружающих 
(надеемся и рассчитываем на это) влияет на авторов деструкторов и функ- 
ций орегаіог ае1ете объектов, на которые ссылаются рїгі_ и ріг2_. Эти 
страхи тоже могут быть нам полезными и упростить задачу: 
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Х::-Х() 4 
де1ете рїг1_; 
де1ете рїг2_; 

} 


Аксиома 3: обмен значениями не формирует 
исключение 


Есть еще одна сформированная общественным мнением аксиома, но она 
не настолько прочно укоренилась, как запрет формирования исключений 
в деструкторах и при удалении. Обмен значениями — не очень распро- 
страненная операция, но она широко применяется «за кулисами», осо- 
бенно в реализациях БТГ.. Обмен значениями происходит при любой сор- 
тировке, разбиении на разделы и множестве других операций. И надеж- 
ный обмен значениями очень важен для надежности этих операций. (См. 
также тему 13 «Операции копирования».) 


Тема 39 | Надежные! функции 


Основная трудность в написании надежного кода не в формировании или 
перехвате исключений, а в том, что происходит между указанными собы- 
тиями. По мере того как сформированное исключение прокладывает свой 
путь от выражения {Пгом к блоку саїсһ, каждая частично выполненная 
функция на этом пути должна «очистить» все важные контролируемые 
ею ресурсы до того, как ее активационная запись будет вытолкнута из сте- 
ка выполнения. Обычно (но не всегда) для написания надежной функции 
необходимы только недолгие размышления и немного здравого смысла. 


Например, рассмотрим реализацию присваивания 51г1п9 из темы 12 «При- 
сваивание и инициализация - это не одно и то же»: 


$1г1п9 &51гіпд: :орегаог =( сопзЕ сһаг *ѕїг ) { 
1Р( зїг ) ѕіг = ""; 
сһаг *їтр = ѕігсру( пем сваг[ ѕїг1еп(ѕїг)+1 ], ѕїг ); 
де1ете [1] $; 
$_ = р; 
гефигп *{01$; 


} 


Реализация этой функции может показаться чересчур витиеватой, по- 
скольку ее можно было бы сделать более короткой и не использовать вре- 
менную переменную: 


$1г1п9 &51гіпд: :орегаог =( сопѕі сһаг *ѕїг ) { 
де1ете [1 $; 


ТЕ зїг ) ѕіг = ""; 
$_ = ѕїігсру( пем спаг[ ѕіг1еп(ѕ1г)+1 ], ѕіг ); 


1 Подразумевается надежность в смысле ехсерііоп-ѕаѓеёу. – Примеч. перев. 
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гефигп *{01$ 


} 


Однако если функция уничтожения массива ограничена общественным 
обязательством не формировать исключений (см. тему 38 «Аксиомы на- 
дежности исключений»), функция создания массива, располагающаяся 
несколькими строками ниже, не дает таких обетцаний. Если удалить ста- 
рый буфер до того, как станет известно об успешном выделении нового 
буфера, объект 51г1пд останется в некорректном состоянии. Эта ситуация 
хорошо описана в книге [8]. Передам своими словами: сначала надо сде- 
лать что-то, что могло бы обусловить возникновение исключения без из- 
менения значимого состояния, и затем использовать операции, которые 
не могут сформировать исключения до полного завершения их выполне- 
ния. Это то, что было сделано в первой приведенной выше реализации 
Ѕігіпд: : орегафог =. Давайте рассмотрим другой пример из темы 19 «Ко- 
манды и Голливуд»: 


уоіа Виітоп: :ѕзе+Астіоп( сопзЕ Асііоп хпемАсТіоп ) { 
Асїіоп *Тетр = пемАстіоп->с10пе(); // возможно возникновение исключения 
// без изменения значимого состояния. . . 
де1еїе асііоп_; // затем меняем состояние! 
асііоп_ = фетр; 
} 


Поскольку это виртуальная функция, нам фактически ничего не известно 
о поведении функции с1опе при возникновении исключения, поэтому 
предполагаем худшее. Если операция с1опе проходит успешно, дальше 
выполняются надежные удаление и присваивание указателя. В против- 
ном случае формирование исключения приведет к преждевременному вы- 
ходу из Виї+оп: : ѕеАсііоп без всякого вреда. Программисты на С++ нико- 
гда не пытаются «очищать» код таким образом, делая его ненадежным: 


уоіа Виїтоп: :ѕзе+Астіоп( сопзЕ Асііоп *«пемАсЕтоп ) { 
еее ас+іоп_; // изменяет состояние! 
асііоп_ = пемАсїіоп->с1опе(); // затем может быть 
// сформирует исключение? 


Если уничтожение (предположительно, безопасное) осуществляется пе- 
ред клонированием (которое не дает таких гарантий), и операция клони- 
рования формирует исключение, объект Виііоп остается в неопределен- 
ном состоянии 


Обратите внимание, что в правильно написанном надежном коде блоки 
гу используются сравнительно мало. Пытаясь написать надежный код, 
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новички обильно снабжают его ненужными и подчас разрушительными 
блоками {гу и саїсћ: 


уоіа Виітоп: :ѕе+Астіоп( сопзЕ Асііоп хпемАсЕТоп ) { 
де1ете асїїіоп_; 


гу 4 

асїіоп_ = пемАсіїіоп->с10пе(); 
} 
СА)" 

асііоп_ = 0; 

И гом; 


} 


Эта версия с ее аляповатыми блоками їгу и саїсћ надежна в том смысле, 
что объект Виїїоп остается в непротиворечивом (но, вероятно, изменен- 
ном) состоянии в случае, если с1опе формирует исключение. Однако наша 
предыдущая версия была короче, проще и надежней, потому что объект 
Виїтоп оставался не только непротиворечивым, но и неизмененным. 


Лучше всего свести использование блоков їгу к минимуму и применять 
их главным образом там, где действительно необходимо проверить тип 
передаваемого исключения (чтобы что-то сделать с ним). На практике это 
обычно границы модулей между вашим кодом и библиотеками сторонних 
производителей и между вашим кодом и операционной системой. 


Тема 40 | Методика КАП 


Сообщество разработчиков на С++ имеет долгую и величественную тра- 
дицию загадочных аббревиатур и странных названий методик. ВАП объ- 
единяет в себе и странность, и загадочность. Она расшифровывается как 
«гезоигсе асацпіѕіћіор іѕ шаха оп» — «выделение ресурса есть инициа- 
лизация». (Нет, не «инициализация есть выделение ресурса», как вы 
могли подумать. Если хотите выглядеть странно, вы должны пройти весь 
путь от начала до конца, иначе все пропало.) 


КАП - простая методика, использующая С++-понятие времени жизни 
объекта для управления такими ресурсами программ, как память, де- 
скрипторы файлов, сетевые соединения, журнал аудита ит. д. Базовая тех- 
ника проста. Если необходимо отследить важный ресурс, создается объект 
и время жизни ресурса ассоциируется со временем жизни объекта. Так, 
для управления ресурсами могут использоваться мудреные возможности 
управления объектами С++. Самая простая форма – создается объект, кон- 
структор которого захватывает, а деструктор — высвобождает ресурс. 


с1аѕѕ Незоигсе {... }; 
с1аѕѕ НезоигсеНапа]е { 
рир11с: 
ехр1ісії НезоигсеНапа1е( Везоигсе *аВеѕоигсе ) 
г (аНезоигсе) {} // захват ресурса 
-ВеѕоигсеНапа1е() 


{ деЈеїе г; } // высвобождение ресурса 
Везоигсе *деї() 
{ геъигп г; } // доступ к ресурсу 
ргімаїе: 


ВезоигсеНапта]е( сопѕі НезоигсеНапо1е & ); 
ВезоигсеНапта]е &орегаїог =( сопѕї ВезоигсеНапа]1е & ); 
Везоигсе *г_; 
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В объекте ВезоигсеНапа]е любопытно то, что если он объявлен как локаль- 
ная переменная функции, аргумент функции или статический объект, 
мы гарантированно получаем вызов деструктора, и ресурс восстанавлива- 
ется. Это свойство заслуживает особого внимания, если требуется отсле- 
живать важные ресурсы, а сопровождение кода оставляет желать лучше- 
го или нет спасения от исключений. Рассмотрим простой код, который не 
использует КАП: 


моїіа #() { 
Везоигсе *гћ = пем Везоигсе; 
Е. 
1Р( іғее11ікеІі() ) // результат неудачного сопровождения 
ГОТИ: 
ГОТ 
00); // исключение? 
де1ете гп; // мы всегда сюда попадаем? 


Исходная версия этой функции может быть надежной и всегда восстанав- 
ливать ресурс, на который ссылается гп. Однако со временем такой код 
может начать давать сбои, поскольку менее опытные разработчики вво- 
дят ранние возвраты, вызовы функций, которые могут формировать ис- 
ключения или любым другим способом обходить код восстановления ре- 
сурса в конце функции. При использовании КАП функция становится 
и проще, и надежнее: 


\019 #() { 
ВеѕоигсеНапа1е гй( пем Везоигсе ); 
//... 
іР( 1Еее1акете() ) // по ргор1ет! 
гефигп; 
ИИ 
9(); // исключение? никаких проблем! 


// деструктор гй осуществляет уничтожение! 


} 


При использовании КАП вызов деструктора не гарантируется только в том 
случае, если дескриптор ресурса размещен в куче, потому что тогда де- 
структор вызывается лишь при явном удалении объекта. (Чтобы быть со- 
вершенно точным, необходимо упомянуть пограничные случаи, когда 
вызываются арогї или ехії, и неопределенные ситуации, которые могут 
иметь место, если сформированное исключение не перехватывается.) 


ВезоигсеНапта1е *гйр = 
пем ВезоигсеНаптд1е(пем Веѕоигсе); // плохая идея! 
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КАП настолько распространена в программировании на С++, что трудно 
найти библиотечный компонент или значительный по объему блок кода, 
не использующий ее тем или иным образом. Обратите внимание, что опре- 
деление «ресурса», который может управляться посредством ВАП, очень 
широкое. Кроме ресурсов, фактически являющихся блоками памяти (бу- 
феры, строки, реализации контейнеров ит. д.), КАП можно использовать 
для управления такими системными ресурсами, как дескрипторы фай- 
лов, семафоры и сетевые соединения, а также менее эффектными сеанса- 
ми регистрации, графическими формами или животными зоопарка. 


Рассмотрим следующий класс: 


с1аѕѕ Тгасе { 


рир11с: 
Тгасе( сопѕї сһаг *т59 ) : п$9_(т$9) 
{ за: :сои << "Епегіпо ” << мѕ9_ << а: :епа1; } 
-Тгасе() 
{ $14: :сои << "Геауіпод ” << п59_ << ѕїа: :епа1; } 
ргіуаїе: 


ѕ1а: :5ігіпо 59; 
| 


В случае с классом Тгасе контролируемым ресурсом является сообщение, 
которое должно распечатываться при выходе из области видимости. По- 
лезно проследить поведение разных объектов Тгасе (автоматического, 
статического, локального и глобального), отслеживая их времена жизни 
в различных типах потока управления. 


моїіа #() { 
Тгасе ігасег( "#" ); // распечатываем “входное” сообщение 
ВезоигсеНапа1е гН( пем Везоигсе ); // захват ресурса 
РЕ 
1Р( іҒее11ікеІ() ) // проблем нет! 
гефигп; 
ИИ 
9(); // исключение? никаких проблем 
// деструктор гй осуществляет уничтожение! 


// деструктор їгасег распечатывает сообщение выхода! 
} 


Приведенный выше код также иллюстрирует важный инвариант актива- 
ции структуры конструктора и деструктора – активации из стека. То есть 
їгасег объявляется и инициализируется до гп, благодаря чему гп будет га- 
рантированно уничтожен раньше їігасег (инициализируется последним, 
уничтожается первым). Говоря более обобщенно, когда объявляется по- 
следовательность объектов, эти объекты инициализируются во время вы- 
полнения в определенном порядке и уничтожаются в обратном порядке. 
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Этот порядок уничтожения не изменится даже в случае непредвиденного 
выхода, распространяющегося исключения, необычного ѕміїсһ или ги- 
бельного 9010. (Если это утверждение вызывает сомнения, поработайте 
с классом Тгасе. Очень поучительно.) Это свойство особенно важно для за- 
хвата и высвобождения ресурсов, поскольку обычно ресурсы должны за- 
хватываться в определенном порядке и высвобождаться в обратном по- 
рядке. Например, сетевое соединение должно открываться перед отправ- 
кой контрольного сообщения, а закрывающее контрольное сообщение 
должно отправляться перед закрытием соединения. 


Такое поведение, основанное на структуре стека, распространяется даже 
на инициализацию и уничтожение отдельных объектов. Конструктор 
объекта инициализирует сначала подобъекты своего базового класса 
в порядке их объявления, а затем данные-члены в порядке их объявле- 
ния. После этого (и только тогда) выполняется тело конструктора. Теперь 
нам известно, как будет вести себя деструктор объекта. Проследуем в об- 
ратном порядке. Сначала выполняется тело деструктора, затем уничто- 
жаются данные-члены в порядке их объявления и наконец уничтожают- 
ся подобъекты базового класса объекта в порядке обратном порядку их 
объявления. Когда порядок выполнения не так очевиден, стекоподобное 
поведение оказывается удобным для захвата и высвобождения необходи- 
мых объекту ресурсов. 


Тема 41 | операторы пемм, конструкторы 
и исключения 


Чтобы написать идеальный надежный код, необходимо отслеживать все 
выделенные ресурсы и быть готовым высвободить их в случае возникно- 
вения исключения. Обычно это делается просто. Можно либо организо- 
вать код таким образом, чтобы восстановления ресурсов не требовалось 
(см. тему 39 «Надежные функции»), либо использовать дескрипторы ре- 
сурсов для автоматического высвобождения ресурсов (см. тему 40 «Ме- 
тодика ВАП»). В экстремальных ситуациях можно отставить все услов- 
ности и использовать блоки {гу или даже вложенные блоки їгу, но это 
должно быть исключением, а не правилом. 


Однако существует несомненная проблема с использованием оператора 
пем. На самом деле оператор пем осуществляет две отдельные операции 
(см. тему 35 «Синтаксис размешения пеш»). Сначала он вызывает функ- 
цию орегатог пем для выделения некоторой области памяти, а затем может 
инициировать конструктор, чтобы превратить это неинициализирован- 
ное хранилище в объект: 


$Ё1г1п9 *їії1е = пем 5%г1п9( "Кіскѕ” ); 


Проблема состоит в том, что если возникает исключение, невозможно 
определить, было ли оно сформировано функцией орегаїог пем или конст- 
руктором 51г1п0. Это важно, потому что если выполнение орегаїог пем про- 
шло успешно и исключение сформировал конструктор, вероятно, необхо- 
димо вызвать орегатог ае1ете для выделенного (но неинициализированно- 
го) хранилища. Если исключение сформировала функция орегаїог пем, то 
память не была выделена и нет необходимости вызывать орегаїог де]1ете. 
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Можно вручную обеспечить необходимое поведение, разделив выделение 
и инициализацию и втиснув блок ігу, но это один из самых ужасных ва- 
риантов: 


Ѕігіпо *111е // распределение памяти 
= ѕзїіаїіс саѕї<5їгіпо *>(::орегафог пем(ѕігео?(Ѕїгіпо)); 
ігу { 
пем( 1111е ) Ѕігіпо( "Кіскѕ” ); // синтаксис размещения пем 
} 
САТО 1 
:орегатог де1ете( 1111е ); // очистка ресурсов, если конструктор 
// формирует исключение 
} 


Ой-ой-ой! В этом коде столько ошибок, что данный подход мы не будем 
даже рассматривать. Кроме того, что он добавляет хлопот разработчику, 
и без того заваленному работой, приведенный код не будет вести себя пра- 
вильно, если у 51г1п9 будут члены орегаїог пем и орегатог де1ете (см. те- 
му 36 «Индивидуальное управление памятью»). Это идеальный пример 
заумного кода, который сначала работает, но в будущем дает скрытый 
сбой из-за незначительных изменений (например, если кто-то вводит 
индивидуальное для 51г1п9 управление памятью). 


К счастью, компилятор обрабатывает эту ситуацию и создает код, рабо- 
тающий так же, как приведенный выше «рукотворный» подход, но за од- 
ним маленьким исключением. Он будет вызывать функцию орегаїог @е- 
1ете, соответствующую функции орегаїог пем, используемой для выделе- 
ния памяти. 


Ѕігіпо *1ії16 = пем 5%г1п19( "Кіскѕ” ); // использовать члены, если есть 
бігіпо *1111е = ::пем Ѕїгіпо( "Кіскѕ” ); // использовать глобальный пем/де1е+е 


В частности, если память выделяется при помощи члена орегаїог пем 
и конструктор 5їгіпо формирует исключение, для высвобождения памяти 
будет вызван соответствующий член орегаїог де1ете. Это еще одна веская 
причина объявить член орегаїог де1ете при объявлении члена орегаїог пем. 


В сущности то же самое происходит и при создании массивов, и при рас- 
пределении памяти, когда используются перегруженные версии орегаїог 
пем[ ]. Компилятор будет пытаться найти и вызвать соответствующую оре- 
гатог де1еїе[ ]. 


Тема 42 | Умные указатели 


Мы, программисты на С++, отличаемся особой верностью. Если нам нуж- 
на какая-то возможность, не поддерживаемая языком, мы не предаем 
С++ и не заигрываем с другими языками программирования. Мы просто 
расширяем С++, чтобы он поддерживал ту возможность, которая нам не- 
обходима. 


Например, часто требуется что-то, ведущее себя как указатель. При этом 
встроенный тип указателя не годится. В таких случаях программист на 
С++ будет использовать умный указатель. (Аналогичные соображения 
по поводу указателей на функции ищите в теме 18 «Обзекты-функции».) 


Умный указатель — это тип класса, искусно замаскированный под указа- 
тель, но предоставляющий дополнительные возможности, отсутствую- 
щие у встроенного указателя. Как правило, умный указатель использует 
возможности, предоставляемые конструкторами, деструктором и опера- 
циями копирования класса, для управления доступом или отслеживания 
того, на что он указывает, таким способом, который недоступен встроен- 
ному указателю. 


Все умные указатели перегружают операторы -> и х, чтобы их можно было 
применять со стандартным синтаксисом указателей. (Иногда дело доходит 
до того, что перегружается оператор ->*; см. тему 15 «Указатели на члены 
класса – это не указатели».) Другие умные указатели (в частности, ис- 
пользуемые как итераторы ТІ) перегружают другие операторы указате- 
лей, такие как ++, --, +, -, +=, -= и [] (см. тему 44 «Арифметика указате- 
лей»). Умные указатели часто реализуются как шаблоны классов, чтобы 
ссылаться на разные типы объектов. Вот очень простой шаблон умного ука- 
зателя, проверяющий перед использованием, не является ли он нулевым: 


тетр1ате <+урепате Т> 
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с1аѕѕ СпескеаРТг { 
рир11с: 
ехр1ісії СһескедрРіг( Т *р ) : р (р) 4} 
-СһескедрРіг() { делете р; } 
Г *орегаог ->() { геїигп деї(); } 
Т &орегатог *() { гефигп *деї(); } 
ргімаїе: 
Г *р_; // на что мы указываем 
Г *061() { // проверяем указатель, перед тем как вернуть его 
і?#( 1р) 
ъһгом М№11СһескеаРоіп+ег() 
ге+игп р_; 


} 

СпескеаРЕг( сопѕї СһескеарРіг & ); 

СпескеаРЕг &орегатог =( сопзЕ СһескедРіг & ); 
}: 


Умный указатель должен имитировать встроенный и быть понятным: 


СһескедарРіг<Ѕһаре> $( пем Сігс1е ); 
ѕ->дгам(); // то же, что и (3.орегафог ->())->агам() 


Ключом к этому фасаду является перегруженный орегаїог ->. Оператор -> 
должен быть перегружен как член и обладать довольно необычным свой- 
ством: его можно не указывать при вызове. Иначе говоря, когда написано 
ѕ->ӣгам(), компилятор понимает, что $ не указатель, а объект класса с пе- 
регруженным орегаїог -> (то есть $ – умный указатель). В результате вы- 
зывается перегруженный оператор-член, который возвращает (в данном 
случае) встроенный указатель 5паре *. Затем этот указатель используется 
для вызова функции дгам объекта паре. Если написать это без сокраще- 
ний, получится запутанное выражение (5. орегаїог ->())->ӣгам(), дважды 
использующее оператор ->, один перегруженный и один встроенный. 


Умные указатели обычно перегружают также оператор *, как и оператор 
->, чтобы их можно было использовать для типов, не являющихся клас- 
сами. 


СһескедрРіг<іпі> ір = пем 111; 
*ір = 12; // аналогично 1р.орегафог *() = 12 
(+5). агам(); // используется также для указателя на класс 


Умные указатели широко применяются в программировании на С++, на- 
чиная от дескрипторов ресурсов (см. темы 40 «Методика ВАШ» и 43 «Ука- 
затель аию р" - штука странная») и заканчивая итераторами БТІ, 
обертками указателей на функции-члены ит. д. ит. п. бетрег Наейз!. 


1 «Всегда верен» (лат.) – девиз корпуса морской пехоты. – Примеч. перев. 


Тема 43 | указатель аиќо рїг - штука странная 


Обсуждая ВАП, надо обязательно упомянуть аи{о_р1г.1 Как отмечалось 
в теме 40 «Методика КАП», дескрипторы ресурсов широко применяют- 
ся в программировании на С++. Поэтому стандартная библиотека постав- 
ляет шаблон дескриптора ресурсов, аџїо_рїг, удовлетворяющий большин- 
ству потребностей в дескрипторе ресурсов. Шаблон класса аифо_рЁг слу- 
жит для создания умных указателей (см. тему 42 «Умные указатели»), 
которые знают, как очищать ресурсы после себя. 


($119 $19: :аиіо ріг; // см. тему 23 «Пространства имен» 
аио ріг<Ѕһаре> аЅһаре( пем Сігс1е ); 

аЅһаре->агам(); // рисуем круг 

(хаЅһаре). дгам(); // рисуем еще раз 


Как все хорошо спроектированные умные указатели, аџїо ріг перегружает 
операторы -> и *, чтобы всегда можно было сделать вид, что работаешь со 
встроенным указателем. Указатель аиїо_ ріг обладает многими замечатель- 
ными свойствами. Во-первых, он очень эффективен. Вы никогда не добье- 
тесь лучшей производительности, написав свой код со встроенным указате- 
лем. Во-вторых, когда аџїо ріг выходит из области видимости, его деструк- 
тор высвободит все, на что бы он ни указывал, точно так же, как это сделал 
бы написанный вручную дескриптор указателя. В приведенном выше фраг- 
менте кода объект Сігс1е, на который ссылается аЅһаре, будет уничтожен. 


Третье замечательное свойство аиїо ріг — при преобразованиях он ведет 
себя как встроенный указатель: 


аио ріг<Сігс1е> абігс1е( пем Сігс1е ); 
абпаре = аС1гс1е; 


1 Внастоящее время аџїо_рїг объявлен устаревшим. Стандарт І50 ЛЕС 14882:2011 
рекомендует использовать џпідие_ ріг. – Примеч. науч. ред. 
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При разумном использовании шаблонных функций-членов (см. тему 50 
«Члены-шаблоны») один аџїо рїг может быть скопирован в другой, если 
это возможно для соответствующих встроенных указателей. В приведен- 
ном выше коде аиіо_ріг<Сігс1е> может быть присвоен аџїо_ріїг<һаре>, по- 
тому что Сігс1е * может быть присвоен Ѕһаре * (предполагается, что 
Ѕһаре — это открытый базовый класс Сігс1е). 


В чем аџїо ріг отличается от обычного умного указателя (или даже обыч- 
ного объекта), так это в операциях копирования. Для обычного класса 
операции копирования (см. тему 13 «Операции копирования») не влияют 
на источник копирования. Иначе говоря, если Т – это некоторый тип, 


Та; 
ТЬ( а ); // копирующее создание Ь значением а 
а = б; // присваивание из рк а 


то при инициализации р значением а значение а остается нетронутым, 
и когда р присваивается а, значение р остается нетронутым. Но с аџіо ріг 
все не так! При присваивании аС1гс]е аЅ$һаре, которое мы видим выше, за- 
трагиваются и источник, и цель присваивания. Если аЅһаре был ненуле- 
вым, все, на что он ссылался, удаляется и заменяется тем, на что указывает 
аС1гс1е. Кроме того, аС1гс1е становится нулевым. Присваивание и инициа- 
лизация аџїо_ рїг – это не совсем операции копирования; это операции, ко- 
торые передают управление базовым объектом от одного аџїо ріг другому. 
Правый аргумент присваивания можно рассматривать как «источник», 
а левый — как «приемник». Управление базовым объектом передается от 
источника к приемнику. Это полезное свойство для работы с ресурсами. 


Однако следует избегать применения аџїо ріг в двух распространенных 
ситуациях. Во-первых, они никогда не должны выступать в качестве эле- 
ментов контейнера. Часто эти элементы копируются в рамках контейне- 
ра, и контейнер будет считать, что его элементы подчиняются обычной 
семантике копирования, не задействующей аџїіо ріг,. Умный указатель 
может применяться как элемент контейнера просто потому, что он не 
аиїо ріг. Во-вторых, аиіо ріг должен ссылаться на один элемент, но не на 
массив. Причина в том, что при уничтожении объекта, на который ссыла- 
ется аџіо ріг, будет вызвана орегаїог йе1еїе, а не функция уничтожения 
массива. Если аџїо_ ріг ссылается на массив, будет вызван несоответст- 
вующий оператор уничтожения (см. тему 87 «Создание массивов»). 


уесіог< аџёо рїг<$һаре> > ѕһареѕ;, // скорее всего ошибка, неудачная идея 
аџто ріг<іпї> 1п$( пем іпї[32] ); // неудачная идея, ошибки нет (пока) 


В общем стандартные уесфог или ѕігіпо представляют собой разумную 
альтернативу аиїо ріг для массива. 


Тема 44 | Арифметика указателей 


Арифметика указателей проста. Чтобы понять ее принцип в С++, лучше 
всего рассмотреть указатель на массив: 


соп$Е іпїі МАХ = 10; 
ѕһогі роіпїѕ[ МАХ]; 
Ѕһогї *сигРоіпі = роіпіѕ+4; 


Это дает нам массив и указатель примерно на середину массива (рис. 44.1). 


роїіпі$+4 
сигРоіпі-3 
--сигРоіпї ++сигРоіпї 
роїпі$: 77 | 
сигРоіпі-=2 


сигРоіпі+1 сигРоіпї [4] 


сигРоіпі: 


Рис. 44.1. Результат различных арифметических операций над адресом, 
содержащимся в указателе 


Давая положительное или отрицательное приращение указателю сигРоіпї, 
мы перемещаем его на следующий или предыдущий элемент ѕһогі масси- 
ва роіпіѕ. Другими словами, арифметика указателей всегда масштабиру- 
ется соответственно размеру объекта, на который они указывают. Прира- 
щение сигРоіпї на единицу не добавляет один байт к адресу указателя, до- 
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бавляется 5ѕі76о#(ѕһогїі) байт. Вот почему арифметика указателей не мо- 
жет применяться к указателям \014 *: неизвестно, на объект какого типа 
ссылается \014 х, поэтому невозможно правильно отмасштабировать опе- 
рации. 


Единственный случай, когда эта простая схема, кажется, приводит к пу- 
танице, — это многомерные массивы. Неопытные программисты на С++ 
забывают, что многомерный массив — это массив массивов: 


сопзф іпі ВОМ = 2; 

Соп5ї іпі С015 = 3; 

іп +аріеГАОИ5 1015]; // массив ВОМ5 массивов, каждый из которых содержит 
// С0Е$ элементов типа іп 

іп (*рёар1е)[С015] = +аріе, // указатель на массив из С0Е$ элементов типа іпї 


Двумерный массив, показанный на рис. 44.2, удобно представить как 
таблицу, несмотря на то, что на самом деле в памяти он располагается ли- 
нейно (рис. 44.8). 


тар1е:; 0,0 0, 1 0,2 


1,0 1,1 12 


Рис. 44.2. Двумерный массив концептуально является таблицей 


ріар1е ріар1е+1 ріар1е[2] 


Рис. 44.3. На самом деле двумерный массив является линейной 
последовательностью одномерных массивов 
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В случае применения арифметики указателей к р{таб]е приращения, как 
всегда, масштабируются соответственно размеру объекта, на который ука- 
зывает рта ]е. Но этот объект имеет тип массива из 0015 целочисленных 
элементов (его размер равен $17е01(1п1)*С015 байт), а не іпі. 


Над указателями одного типа может быть проведена операция вычита- 
ния. В результате получаем количество объектов (а не байтов), находя- 
щихся между этими двумя указателями. Если первый указатель больше 
(указывает на область памяти с большим адресом), чем второй, то резуль- 
тат будет положительный; в противном случае – отрицательный. Если 
два указателя ссылаются на один и тот же объект или оба являются нуле- 
выми, в результате будет получен нуль. Тип результата вычитания двух 
указателей — стандартное переименование типа рігіі?ї?_ї, который обыч- 
но является псевдонимом для іпі. Два указателя нельзя подвергнуть опе- 
рациям сложения, умножения или деления, потому что они просто не 
имеют смысла для адресов. Указатели – это не целые числа (см. тему 35 
«Синтаксис размещения пеш»). 


Эта обычно понятная концепция арифметики указателей используется 
в качестве модели при проектировании итераторов БТИ, (см. темы 4 «Стан- 
дартная библиотека шаблонов» и 42 «Умные указатели»). Итераторы 
ӨТІ, также допускают указателеподобную арифметику, в которой исполь- 
зуется синтаксис, аналогичный встроенным указателям. По сути, встро- 
енные указатели представляют собой совместимые итераторы БТГ.. Рас- 
смотрим возможную реализацию контейнера БТІ, «список» (рис. 44.4). 


іїег 


151 
К Е => 
1 2 3 4 


Рис. 44.4. Возможная реализация стандартного списка. Итератор списка 
не является указателем, но он смоделирован как указатель 


Такая конфигурация могла бы возникнуть в результате выполнения сле- 
дующего кода: 


іпі а[] = { 1, 2, 3,4}; 

$9: :1іѕ1<іпі> 151(а, а+4); 
ѕа::1151<іпі>::іїегаїог 1%ег = 151. рөдіп(); 
++ітег; 
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Итератор списка не может быть встроенным указателем, а является ум- 
ным указателем с перегруженными операторами. Операция ++іїег указа- 
телеподобной арифметики не дает приращения іїег так, как это было бы 
при приращении указателя. Она перемещает ссылку от текущего узла 
списка к следующему. Однако аналогия с арифметикой для встроенных 
указателей абсолютная: операция приращения перемещает итератор 
к следующему элементу списка, так же как приращение встроенного ука- 
зателя перемещает его к следующему элементу массива. 


Тема 45 | Терминология шаблонов 


Строго соблюдать терминологию важно в любой технической области, 
особенно в программировании, еще важнее в программировании на С++ 
и исключительно важно в программировании на С++ с использованием 
шаблонов. 


Наиболее важные аспекты терминологии шаблонов С++ иллюстрирует 
рис. 45.1. 


список параметров шаблона 


се < | Турепате Т> 


с1азз |Неар! < 


сетр1ате < |+урепате Т 


еар<Т_*>} 


Ф 
кеј 
[«%] 


имя шаблона 


идентификатор шаблона 


список аргументов шаблона 


(е/< |Турепате Т 
мо19 [рее |< сопѕ+ Т ёх) {... 


Рис. 45.1. Терминология шаблонов. Строгое соблюдение терминологии 
исключительно важно для точности передачи конструкции шаблона 
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Особенно четко надо различать параметр шаблона, который задается 
в объявлении шаблона, и аргумент шаблона, указываемый в специализа- 
ции шаблона. 


епр1а+е <+урепате Т> // Т - параметр шаблона 
с1аѕѕ Неар { ... }; 


//... 


Неар<доџир1е> аНеар; // 9оу6б1е - аргумент шаблона 


Кроме того, надо четко различать имя шаблона, которое является про- 
стым идентификатором, и идентификатор шаблона, представляющий со- 
бой имя шаблона со списком аргументов птаблона. 


Большинство программистов на С++ путают «создание экземпляра» 
и «специализацию». Специализация шаблона - это то, что получается, ес- 
ли снабдить шаблон набором аргументов шаблона. Специализация может 
быть явной или неявной. Например, записывая Неар<1п{>, мы явно специ- 
ализируем класс Неар аргументом іпї. При записи ргіпі( 12.3 ) имеет место 
неявная специализация шаблона функции ргіпї аргументом доц] е. Спе- 
циализация шаблона может приводить к созданию экземпляра шаблона. 
Так, если доступна версия Неар для іпї, специализация Неар<іпї> будет 
ссылаться на эту версию, экземпляр не будет создаваться (см. тему 46 
«Явная специализация шаблона класса»). Однако если используется 
базовый! шаблон Неар или частичная специализация (см. тему 47 «Час- 
тичная специализация шаблонов»), экземпляр будет создаваться. 


1 Базовым шаблоном называется общий случай вида: 
епріа+е<+урепате Т1, +урепате Т2, .., Турепате Т№ МуС1азз { .. }; 
Подробнее см. тему 46. – Примеч. науч. ред. 


Тема 46 | Явная специализация 
шаблона класса 


Осуществить явную специализацию шаблона класса легко. Во-первых, 
необходим общий случай, который требуется специализировать. Этот об- 
щий случай называют базовым шаблоном. 


тетр1ате <+урепате Т> с1аѕѕ Неар; 


Чтобы провести специализацию базового шаблона, его достаточно объ- 
явить (как приведенный выше Неар), но обычно его еще и определяют 
(как Неар ниже): 


Тетр1афе <+урепате Т> 
с1аѕѕ Неар { 
рир11с: 
уоіа риѕћ( сопѕі Т ёуа1 ); 
Т рор(); 
роо1 етр+у() сопѕі { гефигп һ_.етр+у(); } 
ргіуаїе: 
51а: :месТтог<Т> ћ_; 
| 


Наш базовый шаблон реализует структуру данных кучи, скрывая запу- 
танные алгоритмы работы с кучей за удобным в работе интерфейсом. Ку- 
ча – это линеаризованная структура типа дерево, оптимизированная для 
ввода и извлечения данных. Операция вставки в кучу есть вставка элемен- 
та в древоподобную структуру. Операция извлечения из кучи есть удале- 
ние наибольшего элемента этой кучи и возврат его значения в качестве 
результата. Например, операции риѕћ и рор могут реализовываться с по- 
мощью стандартных алгоритмов ризп_пеар и рор_Пеар: 
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тетр1ате <+урепате Т> 

уоіа Неар<Т>: :риѕћ( сопѕї Т &\а1 ) { 
ћ_.риѕћ раск(уа1); 

ѕ+а: :риѕћ_ һеар( һ_. бедіп(), һ_.епа() ); 


Тетр1ате <+урепате Т> 

Т Неар<Т>::рор() { 

а: :рор_һеар( һ_. редіп(), һ_.епа() ); 
Т +тр( һ_.раск() ); 

ћ_. рор баск(); 

геъигп тр; 


[92] 


} 


Данная реализация хорошо работает для многих типов значений, но дает 
сбой для указателей на символы. По умолчанию стандартные алгоритмы 
работы с кучей для сравнения и организации элементов кучи задейству- 
ют оператор <. Однако в случае с указателями на символы это привело бы 
к тому, что куча организовывалась бы по адресам строк, на которые ссы- 
лаются указатели символов, а не по самим значениям строк. Другими 
словами, по значениям указателей, а не по значениям того, на что они 
указывают. 


Решить эту проблему можно путем явной специализации базового шабло- 
на Неар для указателей на символы: 


Тетр1ате <> 
с1аѕѕ Неар<сопѕі сһаг *> { 
рир11с: 
уоіа риѕћ( сопѕі сһаг *руа1 ); 
сопѕЇі сһаг *рор() 
роо1 етрїу() сопѕї { гефигп һ_.етрїу(); } 
ргімаїе: 
51а: : месТог<сопѕї сһаг *> һ_; 
}; 


Список параметров шаблона пуст, но аргумент шаблона, для которого 
создается специализация, добавлен к имени шаблона. Любопытно, что 
эта явная специализация шаблона класса не есть шаблон, потому что 
в ней не осталось неопределенных параметров шаблона. Поэтому явную 
специализацию шаблона класса обычно называют полной спеииализаци- 
ей, чтобы отличить ее от частичной специализации, которая является 
шаблоном (см. тему 47 «Частичная специализация шаблонов»). 


Терминология в данной области несколько запутанная. Специализация 
шаблона – это имя шаблона с предоставленными аргументами шаблона 
(см. тему 45 «Терминология шаблонов»). Синтаксис Неар<сопѕї спаг *> — 
это специализация шаблона, как и Неар<іпі>. Однако первая специализа- 
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ция не приведет к созданию экземпляра шаблона Неар (потому что будет 
использоваться явная специализация, определенная для сопѕї спаг *). 
А вот вторая специализация обусловит создание экземпляра базового 
шаблона Неар. 


Реализация специализации может быть настроена соответственно нуж- 
дам типа элемента сопѕї сһаг *. Например, операция риѕћ может вставлять 
в кучу новое значение на основании значения строки, на которую ссыла- 
ется указатель, а не адреса, содержащегося в указателе: 


6001 ѕїгіеѕѕ( сопѕї сһаг ха, сопѕї сһаг *б ) 
{ гетигп ѕїгстр( а, р) < 0; } 


уоіа Неар<сопѕї сһаг *>; :риѕћ( сопѕї сһаг *руа1 ) { 
ћ_.риѕћ баск(руа1); 
ѕ+а: :риѕћ_ һеар( һ_. редіп(), һ_.епа(), ѕігіеѕѕ ); 
} 


Обратите внимание на отсутствие ключевого слова їепр1аїе («шаблон») 
и списка параметров в определении Неар<сопз{ спаг *>: :риѕћ. Это не шаб- 
лон функции, потому что, как отмечалось ранее, явная специализация 
Неар<сопзї спаг *> — это не шаблон. 


Имея в распоряжении эту полную специализацию, мы можем отличать 
Неар для типа сопѕї сһаг * от прочих Неар: 


Неар<іпї> 11; // используется базовый шаблон 
Неар<сопѕї сһаг «> 12; // используется явная специализация 
Неар<сһаг *> һ3; // используется базовый шаблон! 


Компилятор сравнивает специализацию шаблона класса с объявлением 
базового шаблона. Если аргументы шаблона соответствуют базовому шаб- 
лону (в случае с Неар, если имеется единственный аргумент, указываю- 
щий имя типа), компилятор будет искать явную специализацию, точно 
соответствующую аргументам шаблона. Если мы хотим специализиро- 
вать Неар для типа спаг * в дополнение к Неар для типа сопзі сһаг *, необхо- 
димо предоставить дополнительную явную специализацию. 


Тетріате <> 
с1аѕѕ Неар<сһаг *> { 
рир11с: 
уоіа риѕћ( сһаг *руа1 ); 
сһаг *рор(); 
51701 5170() СопѕЇ; 
уоіа сарі+іа1іхе() 
// метод етріу() отсутствует! 


ргімаїе: 
51а: :местог<сһаг *> һ_; 
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}; 


Обратите внимание на отсутствие требования обязательного совпадения 
между интерфейсами явной специализации и базового шаблона. Напри- 
мер, в первой явной специализации Неар для сопѕі сһаг * тип формального 
аргумента функции риз! был объявлен как сопѕї сһаг *, а не сопѕї спаг *&. 
Это разумная оптимизация для аргумента указателя. В специализации 
Неар для спаг * интерфейс еще больше отличается от интерфейса базового 
шаблона. 


Добавлены две новые функции - $176 (вычисление размера) и сар1{а117е 
(преобразование из строчных в заглавные), обе допустимые и иногда по- 
лезные, и исключена другая — өпрїу (пустой), что допустимо, но в общем 
не рекомендуется. Обдумывая интерфейсы явных специализаций шабло- 
нов классов, полезно провести аналогию с отношением между базовым 
и производными классами (хотя явная специализация шаблона класса не 
имеет абсолютно никакой связи с производными классами). Пользовате- 
ли иерархии класса часто пишут в интерфейсе базового класса полиморф- 
ный код, предполагая, что производный класс реализует этот интерфейс 
(см. тему 2 «Полиморфизм»). Аналогично, в интерфейсе, предоставляе- 
мом в базовом шаблоне, обычно располагается универсальный код (если 
базовый шаблон объявляется и определяется) и предполагается, что лю- 
бая специализация будет, по крайней мере, иметь такие возможности 
(хотя, как и в производных классах, в ней могут быть и дополнительные 
возможности). Рассмотрим простой шаблон функции: 


Тетр1ате <Турепате Т, Турепате Оиї> 
уоіа ехігасїНеар( Неар<Т> &һ, Ои? деѕї ) { 
мһі1е( !һ. етр+у() ) 
*0651++ = һ.рор(); 
} 


Автор этого шаблона функции плохо подумает об авторе явной специали- 
зации Неар для сһаг *, если данный код будет работать: 


Неар<соп$Е сһаг *> һеар1; 


И 
уесфтог<сопзЕ сһаг *> уес1; 
ехфгасЕНеар( һеарі, баск іпѕегіег(мес1) ); // хорошо... 


а этот код не скомпилируется: 


Неар<сһаг *> Пеар2; 


//... 


уестог<спаг *> үес2; 
ехігас+Неар( һеар2, баск іпѕегіег(мес2) ); // ошибка! функция-член етрту() 
// отсутствует в явной специализации Неар для сһаг * 


Тема 47 | Частичная специализация 
шаблонов 


Давайте уточним: нельзя частично специализировать шаблоны функций. 
Этой возможности просто нет в С++ (хотя возможно, что когда-нибудь 
она появится). Их можно перегрузить (см. тему 58 «Перегрузка шаблонов 
функций»). Так что мы будем рассматривать только шаблоны классов. 


Принцип частичной специализации шаблона класса прост. Как и в слу- 
чае с полной специализацией, сначала необходим общий случай, или ба- 
зовый шаблон, который будет подвергнут специализации. Воспользуемся 
шаблоном Неар из темы 46 «Явная специализация шаблона класса»: 


Тетр1афе <+урепате Т> с1аѕѕ Неар; 


Явная специализация (в просторечии «полная специализация») исполь- 
зуется, чтобы снабдить шаблон класса определенным набором аргумен- 
тов. В теме 46 «Явная специализация шаблона класса» явная специали- 
зация применялась, чтобы предоставить специальные реализации Неар 
для сопѕї сһаг * и сһаг *. Однако нерешенной остается проблема с Неар для 
других типов указателей: хотелось бы упорядочивать Неар по значениям, 
на которые ссылаются элементы указателей, а не по значениям самих 
указателей. 


Неар<доџр1е *> геайіпдѕ; // базовый шаблон, Т - это йоџр1е * 


Поскольку тип (00и01е *) не соответствует ни одной из наших полных спе- 
циализаций указателя на символ, компилятор создаст экземпляр базового 
шаблона. Можно было бы обеспечить полные специализации для дои]е * 
и любого другого типа указателя, но это очень трудно и абсолютно непри- 
годно к сопровождению. Это задача частичной специализации: 


тетр1ате <+урепате Т> 
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с1аѕѕ Неар<Т => { 


рир11с: 

уоіа риѕћ( сопѕі Т хуа1 ); 

Т *рор(); 

роо1 етрїу() сопѕї { гефигп һ_.етрїу(); } 
ргімаїе: 


$14: ;уесТог<Т *> ПН! 
}; 


Синтаксис частичной специализации подобен синтаксису полной специа- 
лизации, но список параметров не пуст. Как в полной специализации, 
имя шаблона класса – это идентификатор шаблона, а не просто имя шаб- 
лона (см. тему 45 «Терминология шаблонов»). 


Частичная специализация для указателей позволяет изменять реализа- 
цию. Например, вставки могут осуществляться на базе значения объекта, 
на который указывает указатель, а не значения указателя. Сначала да- 
вайте возьмем компаратор, сравнивающий два указателя по значениям, 
на которые они указывают (см. тему 20 «Объекты-функции 5ТГ»): 


Тетр1афе <+урепате Т> 
ѕігисї РАгСтр : рир1іс $14: :ріпагу ЁипсТіоп<Т *, Т =», боо1> { 
6001 орега+ог ()( сопѕї Т ха, сопѕї Т хр ) сопѕ+ 
{ геїигп ға < *р; } 
}; 


Теперь применим этот компаратор для реализации необходимого поведе- 
ния операции риѕћ: 


Тетр1афе <+урепате Т> 
уоіа Неар<Т *>::риѕћ( Т *руа1 ) { 
1?( рма1 ) { 
ћ_.риѕћ раск(руа1) 
ѕ+а: : ризп_пеар( һ_. редіп(), һ_.епа(), РігСтр<Т>() ); 
} 
} 


Обратите внимание, что, в отличие от полной специализации шаблона 
класса, частичная специализация представляет собой шаблон. Ключевое 
слово їепр1а+е и список параметров обязательны в определениях ее членов. 


В отличие от приводимых выше полных специализаций, тип параметра 
этой версии Неар определен не полностью. Лишь частично определено, что 
это должен быть Т *, где Т – неопределенный тип. Именно поэтому данная 
специализация частичная. И ее приоритет при создании экземпляра Неар 
для любого (неопределенного) типа указателя будет выше, чем приоритет 
базового шаблона. Кроме того, полные специализации Неар для сопѕї спаг * 
и сһаг * будут предпочтительнее этой частичной специализации, если ти- 
пом аргумента шаблона будет сопѕї сһаг * или спаг *. 
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Неар<51а: :ѕ1гіпо> |1; // базовый, Т является $14: : ѕїгіпо 

Неар<ѕїа: :ѕігіпо *> ћ2; // частичная специализация, Т является $14: : ѕігіпо 
Неар<іпі **> ПЗ; // частичная специализация, Т является іпі + 
Неар<сһаг *> һ4; // полная специализация для спаг * 

Неар<сһаг **> һ5; // частичная специализация, Т является сһаг * 
Неар<сопѕї іпі *> һ6; // частичная специализация, Т является сопз іпї 
Неар<іпі (*)()> 17; // частичная специализация, Т является іпї () 


Полный набор правил выбора частичной специализации из множества 
доступных довольно запутан, но в большинстве случаев делается это про- 
сто. Обычно выбирается самый специализированный, самый ограничен- 
ный вариант из возможных. Механизм частичной специализации точен 
и позволяет практически безошибочно выбирать необходимую версию. 
Например, можно было бы дополнить наш набор частичных специализа- 
ций вариантом с указателем на константу: 


Тетр1афе <+урепате Т> 

с1аѕѕ Нвар<сопѕї Т *> { 
Ах 

}; 

е 


Неар<сопѕї іпі *> һ6; // другая частичная специализация, теперь Т является іпї 


Обратите внимание, что, как обсуждалось в теме 46 «Явная специализа- 
ция шаблона класса», компилятор сравнивает специализацию шаблона 
класса с объявлением базового шаблона. Если аргументы шаблона совпа- 
дают с аргументами базового шаблона (в случае с Неар — если есть единст- 
венный аргумент имени типа), компилятор будет искать полную или час- 
тичную специализацию, более всего соответствующую аргументам шаб- 
лона. 


Обратите внимание на такую тонкость: экземпляр полной или частичной 
специализации базового шаблона должен создаваться с таким же числом 
и типом аргументов, как и в базовом шаблоне, но форма списка парамет- 
ров шаблона может отличаться от базового шаблона. В случае с Неар базо- 
вый шаблон принимает единственный параметр – имя типа. Таким обра- 
зом, экземпляр любой полной или частичной специализации Неар должен 
создаваться с единственным аргументом - именем типа: 


тетр1ате <+урепате Т> с1аѕѕ Неар; 


Следовательно, полная специализация Неар по-прежнему принимает един- 
ственный аргумент шаблона – имя типа, но список параметров шаблона 
отличается от списка базового шаблона, потому что он пуст: 


тетр1ате <> с1аѕѕ Неар<сһаг *>; 
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Частичная специализация Неар также должна принимать единственный 
аргумент шаблона – имя типа, и ее список параметров шаблона может со- 
держать единственный параметр (имя типа) в заголовке шаблона: 


Тетр1афе <+урепате Т> с1азз Неар<Т =>; 
но это не обязательно. 
Тетр]афе <+урепате Т, іп п> с1азз Неар<Т [п]>; 


Эта частичная специализация будет выбрана для специализации Неар для 
массива. Например: 


Неар<#1оаї *[6]> 18; // частичная специализация, Т является Ғ10оаї *, и п равно 6 


Эта частичная специализация гласит: «Данная частичная специализа- 
ция принимает единственный параметр типа как базовый шаблон, но 
этот параметр должен иметь форму массива Т размером п элементов». Рас- 
смотрим несколько более сложных примеров: 


Тетр1ате <Турепате В, Турепате А1, Турепате А2> 
с1аѕѕ Неар<Н (*)(А1, А2)>; 


тетр1ате <с1а55 С, Турепаме Т> 
с1а55 Неар<Т С: :*>; 


С добавлением частичных специализаций появилась возможность обра- 
батывать случаи для Неар из указателей на функции-нечлены, принимаю- 
щие два аргумента, и из указателей на данные-члены (хотя зачем могут 
понадобиться такие кучи, остается только догадываться): 


Неар<сһаг *(*) (іпі, іпї)> һ9; // частичная специализация 

// В является сһаг *, А1 и А2 являются іпї 
Неар<ѕїа: :зігіпо Мате: :+> һ10; // частичная специализация 

// Т является зігіпо, С является Мате 


Тема 48 | Специализация членов 
шаблона класса 


По поводу явной и частичной специализаций шаблона класса широко 
распространено заблуждение, что специализация каким-то образом «на- 
следует» что-то от базового шаблона. Это не так. Полная или частичная 
специализация шаблона класса — это совершенно самостоятельная сущ- 
ность, которая не «наследует» ни интерфейс, ни реализацию базового 
шаблона. Однако если оставить в стороне технические вопросы, специа- 
лизации действительно наследуют ряд ожиданий, касающихся интер- 
фейсов и поведения. Поэтому пользователи, создающие универсальный 
код для интерфейса базового шаблона, обычно ожидают, что этот код бу- 
дет работать и со специализациями. 


Это подразумевает, что полная или частичная специализация должна 
в целом реализовать все возможности базового шаблона, даже если спе- 
циализации требуется только часть реализации. Альтернативным реше- 
нием часто является специализация лишь подмножества функций-чле- 
нов базового птаблона. Рассмотрим базовый шаблон Неар (см. тему 46 «Яв- 
ная спеииализация шаблона класса»): 


Тетр1афе <+урепате Т> 
с1аѕѕ Невар { 
рир11с: 
уоіа риѕћ( сопѕі Т ёуа1 ); 
Т рор(); 
6001 етрїу() сопѕї { гефигп һ_.етрїу(); } 
ргіхаїе: 
51а: :месТтог<Т> ћ_; 
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Наша полная специализация Неар для сопз{ сһаг * заменила всю реализа- 
цию базового шаблона, даже несмотря на то, что его закрытая реализа- 
ция и пустая функция-член идеально подходили для кучи указателей 
символов. Фактически надо было лишь специализировать функции-чле- 
ны рип и рор: 


Тетр1афе <> 

уоіа Неар<сопѕї спаг *>; :риѕћ( сопѕї сһаг *сопѕї &руа1 ) { 
_.риѕћ_раск(руа1); 

ѕ+а: :риѕћ_ һеар( һ_. редіп(), һ_.епа(), ѕігіеѕѕ ); 
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} 


Тетр1іате<> 

сопзі сһаг *Неар<сопѕі сһаг *>::рор() { 

а: :рор_һеар( һ_. редіп(), һ_.епа(), ѕїгіеѕѕ ); 
сопѕї сһаг *їтр = һ_. раск(); 

һћ_.рор баск(); гефигп тр; 


[р] 


} 


Данные функции представляют собой явные специализации соответству- 
ющих членов базового шаблона Неар. Они будут использоваться вместо не- 
явно созданных экземпляров специализаций Неар<сопѕї спаг *>. 


Обратите внимание, что интерфейс каждой из этих функций должен точ- 
но совпадать с соответствующим интерфейсом шаблона, члены которого 
они специализируют. Например, в базовом шаблоне объявлено, что риѕћ 
принимает аргумент типа сопѕї Т &. Таким образом, в явной специализа- 
ции риѕћ для сопѕї сһаг * должен быть аргумент типа сопѕї спаг *сопѕї &. 
(То есть ссылка на константный указатель на константный символ.) За- 
метьте, что этого ограничения не было, когда речь шла о полной специа- 
лизации шаблона Неар в целом, где аргументом для риѕћ был объявлен 
просто сопѕї спаг *. 


Увеличим уровень сложности (а это типично для программирования с при- 
менением шаблонов) и посмотрим, что произойдет, если в нашем распо- 
ряжении будет частичная специализация Неар для указателей в целом 
(см. тему 47 «Частичная специализация шаблонов»): 


Тетр1афе <+урепате Т> 
с1аѕѕ Неар<Т => { 
а 
уоіа риѕћ( Т *руа1 ); 
аа 
}; 


Если эта частичная специализация Неар существует, то наша явная спе- 
циализация риѕһ должна соответствовать интерфейсу члена риѕћ частич- 
ной специализации, поскольку в противном случае для Неар<сопз1т сһаг *> 
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создавался бы экземпляр этой функции. Теперь явную специализацию 
необходимо объявить так: 


Тетр1ате <> 
уоіа Неар<сопѕї сһаг *>: :риѕћ( сопѕї сһаг *руа1 ) { 
ћ_.риѕћ баск(руа1); 
эта: :риѕһ_һеар( һ_. редіп(), һ_.епа(), ѕїгіеѕѕ ) 
} 


Два последних замечания. Во-первых, в дополнение к функциям-членам 
могут быть созданы явные специализации для других членов шаблонов 
класса, включая статические члены и члены-шаблоны. 


Во-вторых, люди часто путают явную специализацию и явное создание 
экземпляра. Как было показано выше, явная специализация — это сред- 
ство предоставления специальной версии шаблона или члена шаблона, 
которая отличается от того, что можно получить в результате неявного 
создания экземпляра. Явное создание экземпляра прямо указывает ком- 
пилятору создать член, идентичный тому, который можно получить при 
неявном создании экземпляра. 


епр1а+е уоіа Неар<аоир1е>: :риѕћ( сопѕїі доџр1е & ); 


Обратитесь также к теме 61 «Мы создаем экземпляр того, что исполь- 
зуем». 


Тема 49 | Устранение неоднозначности 
с помощью ключевого слова 
{урепате 


Даже опытных разработчиков на С++ часто смущает слишком сложный 
синтаксис программирования с применением шаблонов. Из всех синтак- 
сических кульбитов, которые приходится при этом выделывать, ни один 
так не сбивает с толку с самого начала, как необходимость помогать ком- 
пилятору в устранении неоднозначности синтаксического анализа. 


В качестве примера рассмотрим часть реализации шаблона простого не- 
стандартного контейнера. 


Тетр1афе <+урепате Т> 
с1аѕѕ Рігііѕї { 
рир11с: 
Н 
уреде? Т хЕ1етт; 
\014 1пзегЕ( Е1етт ); 
Е 
}; 


Распространенная практика – встраивание информации о шаблоне по- 
средством вложенных имен типов. Благодаря этому становится возмож- 
ным получить информацию об экземпляре шаблона через соответствую- 
щее вложенное имя (см. темы 53 «Встроенная информация о типе» и 54 
«Свойства»). 


Туредег Рїгі151<5їате> Ѕїаеііѕі; 


//... 
ЅтатеГіѕі: : Еетт сиггепіЅтаїе = 0 
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Вложенное имя Е1епТ обеспечивает возможность простого доступа к тому, 
что шаблон Ріг іѕї считает типом своего элемента. И хотя при создании эк- 
земпляра Ріг 151 использовалось имя типа Ѕїаїе, типом элемента является 
Отате *. При других обстоятельствах Рїгііѕї мог бы быть реализован с по- 
мощью умных указателей. Кроме того, Р+г!15{ может менять свою реали- 
зацию в зависимости от свойств типа, используемого для создания ее эк- 
земпляра (см. тему 52 «Создание специализации для получения информа- 
ции отипе»). Вложенные имена типов помогают изолировать пользова- 
телей Ртг| 151 от этих внутренних решений реализации. 


Вот еще один нестандартный контейнер: 


Тетр1афе <+урепате Ефуре> 
С1азз$ 5Со11ес+ііоп { 
рир11с: 
И 
уреде? Еуре Е1етт; 
уо1іа іпѕегі( сопѕї Еуре & ); 
л 
}; 


Оказывается, что 5С011өсїіоп спроектирован в соответствии с теми же 
стандартами присваивания имен, что и Ріг 151, потому что он тоже опре- 
деляет вложенное имя типа Е1етТ. Соблюдать установленное соглашение 
полезно, потому что (наряду с другими преимуществами) это позволяет 
создавать универсальные алгоритмы, работающие с целым рядом различ- 
ных типов контейнеров. Например, можно было бы написать простой по- 
лезный алгоритм, заполняющий соответствующий шаблон содержимым 
массива элементов соответствующего типа: 


тетр1ате <с1а55 Сопї> 
моіа #111( Сопї &с, Сопї: :ЕЛетт а[], іпё 1еп ) { // ошибка! 
Ғог( іп і = 0; 1 < 1еп; ++і ) 
с.іпѕегі( а[1] ); 
} 


К сожалению, получаем синтаксическую ошибку. Вложенное имя Сопї: : 
Е1етТ не распознается как имя типа! Беда в том, что в контексте шаблона 
+111 компилятор не располагает достаточной информацией и не может оп- 
ределить, является ли вложенное имя Е1епТ именем типа. Стандарт гла- 
сит, что в подобных ситуациях вложенное имя не считается именем типа. 


Если на первых порах вам это кажется несущественным, вы не одиноки. 
Посмотрим, однако, какая информация доступна компилятору в разных 
контекстах. Сначала рассмотрим ситуацию с нешаблонным классом: 


с1аѕѕ МуСопфалтег { 
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рир11с: 
ТуредеГг Ѕ+ате ЕТеттТ; 
Ин 
}; 
И 
МуСопта1 тег: : ЕТетТ *апЕТетРїг = 0 


Здесь явно никаких проблем. Компилятор может проверить содержимое 
класса МуСопта1тег (Мой контейнер), удостовериться в наличии в нем чле- 
на Е1етГ и отметить, что МуСоптаіпег: : Е1етТ на самом деле представляет со- 
бой имя типа. Все так же просто, как и для класса, сгенерированного из 
шаблона класса. 


уреде? Рігііѕї<5+ате> Ѕіаіеі 151; 


он 
бтатеГіѕі: : ЕТетт азтате = 0; 
Рігііѕі<5+аТе>: :Е1етт апоїһег5+ате = 0 


Для компилятора созданный экземпляр шаблона класса является всего 
лишь классом, и нет никакой разницы в доступе к вложенному имени из 
класса Рїгіѕ1<5їаїе> и из МуСопта1 тег. В любом случае компилятор просто 
проверяет содержимое класса, чтобы определить, является ли ЕетТ име- 
нем типа. 


Однако в контексте шаблона все по-другому, потому что здесь доступно 
меньшее количество точной информации. Рассмотрим такой фрагмент: 


тетр1ате <+урепате Т> 
уоіа аРипсТетр1аїе( Т &аго ) { 
... Г: : ЕТейт... 


Что известно компилятору при встрече с квалифицированным именем 
Т: : Е етт? Из списка параметров шаблона он знает, что Т – это какое-то имя 
типа. Он также может установить, что Т — это имя класса, потому что для 
доступа к вложенному имени Т применен оператор разрешения области 
видимости (::). Но это все, что знает компилятор, потому что о содержи- 
мом Т нет никакой доступной информации. Например, можно было бы вы- 
звать аРипсТетр1ате с Ріг іѕї. В этом случает: : Е1етТ было бы именем типа. 


Рігііѕ1<5+ате> ѕіаїеѕ; 


ИИ 
аРипсТетр1афе( зфафез ); // Т::Еемт является Ріг іѕі<$+ате>: : Е1етт 


Но что если бы надо было создать экземпляр ағипсТетр1а+е другого типа? 


ѕігисі Х { 
епит Турез { +уреА, +уреВ, Туребс } Е1етт; 
ны 

}; 
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Х апх; 


Ива 
ағипсТетр1ате( апх ); // Т::Еетт является Х: : Е1етт 


Здесь Т: : Е1епт — это имя данных -члена, а не имя типа. Что делать компи- 
лятору? Компилятор бросает монетку и, если не может определить тип 
вложенного имени, полагает, что вложенное имя является именем нети- 
па. Что и обусловило синтаксическую ошибку в приведенном выше шаб- 
лоне функции 1111. 


Чтобы справиться с этой ситуацией, иногда необходимо явно сообщить 
компилятору о том, что вложенное имя является именем типа. 


тетр1ате <+урепате Т> 
уоіа аРипсТетр1аїе( Т &аго ) { 
... Сурепаме Т: : ЕТемт. . 


Здесь с помощью ключевого слова іурепапе (имя типа) компилятору явно 
сообщается, что следующее полное имя является именем типа. Это дает 
возможность компилятору правильно проводить синтаксический анализ 
шаблона. Обратите внимание, мы сообщаем компилятору, что имя типа — 
это Е1епт, а не Т. Он уже может определить, что Т – это имя типа. Анало- 
гично следующая запись 


Турепапе А: :В::С::0::Е 
сообщает компилятору о том, что (очень глубоко) вложенное имя Е пред- 
ставляет собой имя типа. 


Конечно, если создается экземпляр аҒипсТепр1ате типа, не удовлетворяю- 
щего требованиям синтаксического анализа шаблона, это приведет к ошиб- 
ке компиляции. 


ѕігисі 2 { 
// нет члена с именем Е1етт. . 


2 а2; 

еа 

аРипсТетр1ате( ах ); // ошибка! нет члена 2: : Еїетт 
аЕипсТетр1ате( апх ); // ошибка! Х: :Е1етТ не является именем типа 


ағипсТетр1аїе( за+еѕ ); // ОК. вложенный Е1епт является типом 


Теперь можно переписать шаблон функции 1111, чтобы синтаксический 
разбор проводился правильно: 


тетр1ате <с1а55 Сопї> 
моіа 1111( Сопї &с, Турепаме Сопї: : Еїетт а[], іп 1еп ) { // 0К 
Рог( 111 = 0; і < 1еп; ++і ) 
с.іпѕегі( а[і] ); 


Тема 50 | Члены-шаблоны 


В шаблонах классов есть члены, сами по себе не являющиеся шаблонами. 
Многие из этих членов могут быть определены вне класса. Рассмотрим 
контейнер, реализующий однонаправленный список: 


Тетр1афе <+урепате Т> 
с1а5 51151 { 
рир11с: 
51151() : һеаа (0) {} 
И 
уоіа риѕћ_ Ғгопї( сопѕї Т &\а1 ); 
уоіа рор #гопі(); 
Т Ғгопі() сопѕї; 
үоіа геуегѕе(); 
роо1 етрїу() сопѕї; 
ргіхаїе: 
ѕігисі №де { 
Моде »*пехі_; 
Те; 


} 
Мае *«Неад_; // -> список 
}; 
Когда функции-члены шаблона определяются вне шаблона класса, они 


имеют заголовок шаблона с такой же структурой, какая используется 
в описании шаблона класса: 


Тетр1ате <+урепате Т> 
роо1 5115Ї<Т>::етріу() сопзі 
{ гефигп һеаа_ == 0; } 


Мы решили реализовать однонаправленный список как указатель на по- 
следовательность узлов, где каждый узел содержит элемент списка и ука- 
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затель на следующий узел списка. (При более сложной реализации усе- 
ченный №де, а не указатель на №оде, мог бы встраиваться в 51151, но для на- 
ших нужд этого достаточно.) Обычно такой вложенный тип класса опре- 
деляется в самом шаблоне, но это необязательно: 


Тетр1ате <Турепате Т> 
с1а5 51151 { 
рир11с: 
Иа 
ргімаїе: 
ѕігисЕ №ае; // неполное объявление класса 
№оае *«пеад_: // -> список 
ИИ 
}; 


їетр1а+е <+урепате Т> // описание вне шаблона 
ѕзігисі 51151<Т>::М№ае { 

Моде *пехї_; 

Те1; 
р: 


Члены епрїу и №ойе – примеры членов шаблонов. Но шаблон класса (или 
даже нешаблонный класс) может иметь члены-шаблоны. (Да, это очеред- 
ной пример, показывающий, как С++ подталкивает программиста к опре- 
делению технических терминов, которые легко перепутать. Это еще одно 
маленькое дополнение к уже известным нам парам – оператор пен и орега- 
Тог пем, ковариантность и контрвариантность, сопѕї іїегаїог и констант- 
ный итератор, — гарантирующим, что каждый обзор конструкции станет 
захватывающим приключением.) В самых лучших традициях тавтологии 
член-шаблон – это член, который представляет собой шаблон: 


тетр1ате <+урепате Т> 
с1а55 51151 { 
рир1іс: 


Гам 
Тетр1афе <+урепате Тп> 51151( Іп редіп, Іп епа ); 


//... 
}; 


Этот конструктор $11ѕї, в отличие от конструктора по умолчанию, являет- 
ся членом-шаблоном, где имя типа Іп – явный параметр. Также он имеет 
неявный параметр — имя типа, используемое для создания экземпляра 
шаблона 51151, членом которого он является. Этим объясняются повторе- 
ния в описании члена-птаблона при его описании вне шаблона класса: 


Тетр1афе <+урепате Т> // для 9181 
Тетр]афе <+урепате Іп> // для члена 
511$1<Т>::51151( Іп 6ед1п, Іп епа ) : һеаа (0 ) { 
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мпі1е( редіп != епа ) 
ризп_Ргопт( *редіп++ ); 
гемегѕе(); 


} 


Как и для других шаблонов функций, компилятор проведет логический 
вывод аргументов и создаст экземпляр шаблона конструктора, когда это 
будет необходимо (см. тему 57 «Логический вывод аргументов шаблона»): 


Ғ1оа+ г9з[] = {... }; 
СопЗЕ іпї $176 = $1276е01(г4$)/з12е01(г4$[0]); 
$14: :уестог<аоџир1е> гаӣѕ2( газ, гіѕ+ѕіхе ); 
х 
511ѕі<Ғ1оаї> да+а( гӣѕ, гӣѕ+ѕіхе ); // Іп является Е1оат * 
Ѕ11іѕ1<доир1е> дафа2( гӣѕ2.редіп(), г52.епа() ); // Іп является 
// месъог<аоир1ө>: :1егафог 


Это обычное применение шаблонов конструкторов в ТІ, позволяющее 
инициализировать контейнер последовательностью значений, извлекае- 
мых из произвольного источника. Члены-шаблоны также служат для ге- 
нерирования функций-членов, подобных конструктору копий и операто- 
ру копирующего присваивания: 


Тетр1афе <+урепате Т> 
с1а55 51151 { 
рир11с: 
Е 
Тетр1афе <+урепате 5> 
51151( сопѕі 51151<5> &їһаї ); 
тетр1ате <+урепате 5> 


51іѕі &орегаїог =( сопѕі 51151<5> &гһѕ ); 
ыы 
}; 


Эти члены шаблона могут применяться для операций, подобных конструк- 
тору копий и копирующему присваиванию: 


511ѕ1<доир1е> дафа3( дата ); // Т является Чоиб1е, 5 является ЁР1оаї 
дата = датазЗ; // Т является Ғ1оаї, 5 является доиб1е 


Обратите внимание на пространные определения «подобный конструкто- 
ру копий» и «подобный копирующему присваиванию» в описании выше. 
Дело в том, что в приведенном выше примере присваивания не будет соз- 
дан экземпляр члена-шаблона. То есть если приведенные выше Ти 5 одно- 
го типа, компилятор не будет создавать член-шаблон, а «напишет» опера- 
цию копирования самостоятельно. В подобных случаях лучше всего явно 
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описывать операции копирования, чтобы предотвратить любезную и обыч- 
но неуместную помощь компилятора: 


тетр1ате <+урепате Т> 
с1а55 51151 { 


5115+1( сопѕї 51151 &1ћат ); // конструктор копий 

Ѕ1іѕі ворегафог =( сопзф 511$ &гһѕ ); // копирующее присваивание 
Тетр1афе <+урепате 5> 51151( сопзЕ 51151<5> &іһаї ); 

Тетр1афе <+урепате 5> 

511іѕі &орегаїог =( сопѕі 51151<5> &гһѕ ); 


Е 
}; 
Иа 
ЅІіѕї<Ғ1оаї> даїа4( дата ); // конструктор копий 
Чата3 = да+а2; // копирующее присваивание 
да+аЗ = даїа4; // некопирующее присваивание из шаблона члена 


Любая невиртуальная функция-член может быть шаблоном (члены-шаб- 
лоны не могут быть виртуальными, потому что сочетание этих характе- 
ристик приводит к непреодолимым техническим проблемам при их реа- 
лизации). Например, для нашего списка можно определить операцию 
сортировки: 


Тетр1афе <+урепате Т> 
с1а55 51151 { 
рир11с: 
И 
Тетр1афе <+урепате Сотр> \019 ѕогї( Сотр сотр ); 
И 
}; 


Член-шаблон ѕ0гі обеспечивает его пользователям возможность переда- 
вать указатель на функцию или объект-функцию, который будет исполь- 
зоваться для сравнения элементов списка (см. тему 20 «Объзекты-функ- 
ции 5ТГ»). 


Чата. ѕогі( $14: :1е3$<Р1о0а*>() ); // восходящая сортировка 
Чата. зогЕ( $14: :огеатег<Ғ1оаї>() ); // нисходящая сортировка 


Здесь созданы экземпляры двух разных версий члена 50гі с помощью 
стандартных объектов-функций 1е55 (меньше) и дгеаїег (больше). 


Тема 51 | Устранение неоднозначности 
с помощью ключевого слова 
їетріІаїе 


В теме 49 «Устранение неоднозначности с помощью имени типа» было 
показано, как важно иногда для обеспечения правильного синтаксиче- 
ского разбора явно сообщить компилятору о том, что вложенное имя яв- 
ляется именем типа. Аналогичная ситуация возникает со вложенными 
именами шаблонов. 


Канонический пример – реализация распределителя ЭТГ.. Если вы не зна- 
комы с распределителями ТІ, ничего страшного. Пока это не обязатель- 
но, но, вероятно, потребуется много терпения. 


Распределитель — это класс, используемый при настройке операций 
управления памятью для контейнеров БТГ.. Распределители обычно реа- 
лизуются как шаблоны классов: 


ТетрТате <с1аз$ Т> 
с1аѕѕ АпА110с { 
рир11с: 
И 
Тетр1ате <с1аѕѕ Оїћег> 
с1аѕ5 геріпа { 
рир1іс: 
Туреде? АпА110с<01һег> оїћег 


Иа 
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Шаблон класса АпА110с содержит вложенное имя геріпа (повторное связы- 
вание), которое само по себе является шаблоном класса. В инфраструктуре 
ТІ, он предназначен для создания распределителей, «аналогичных» рас- 
пределителю, служащему для создания экземпляра контейнера, но для 
другого типа элемента. Например: 


уреде? АпА110с<1пї> АТ; // исходный распределитель 

// распределяет элементы типа іпї 
їурейе? АТ: : геріпа<аоџр1е>: :оїћег А0; // распределяет элементы типа йоир1е 
їурейеғ АпА110с<д0ир1ө> Ад; // допустимо! тип тот же 


Это может показаться странным, но механизм повторного связывания 
позволяет создавать версию существующего распределителя для разных 
типов элементов, не зная о типе распределителя или типе элемента. 


уреде? ЅотеА110с: : геріпа<М№ае>: :оһег М№адеА110с; 


Если имя типа ЅотеА110с соблюдает соглашение ЅТІ, для распределителей, 
в нем должен быть вложенный шаблон класса геріпа. Буквально это озна- 
чает: «Я не знаю, каким распределителем является этот тип, и я не знаю, 
что он размещает, но хочу точно такой же распределитель для размеще- 
ния элементов типа №9е!». 


Этот уровень неведения может иметь место только в рамках шаблона, где 
точные типы и значения неизвестны до момента создания экземпляра 
шаблона. Расширим контейнер $1151 из темы 50 «Члены-шаблоны» , вклю- 
чив в него тип распределителя (А), который может размещать элементы 
(типа Т). Как и все стандартные контейнеры, 51151 предоставит распреде- 
литель по умолчанию: 


Тетр1ате < Турепате Т, с1а55 А = $14: :а110осаїог<Т> > 
с1а55 51151 { 


И 
ѕігисї №ае { 


а 
}; 
уреде? А: : геріпа<№оае>: :оїһег №адеА110с; // синтаксическася ошибка! 


АО 
}; 


Как свойственно спискам и другим основанным на узлах контейнерам, 
наш список элементов типа Т на самом деле не размещает элементы Тине 
управляет ими. Он работает с узлами, содержащими члены типа Т. Дан- 
ная ситуация описывалась выше. Имеется некоторый распределитель, 
знающий, как распределять объекты типа Т, но требуется распределять 
объекты типа №йе. Однако при попытке обращения к геріпі возникает 
синтаксическая ошибка. 


172 


Тема 51 


Повторюсь, проблема состоит в том, что компилятор не располагает 
в данной точке никакой информацией об имени типа А, кроме того, что 
это имя типа. Компилятор вынужден делать предположение о том, что 
вложенное имя геб1п4 является именем нешаблона, и угловая скобка, 
следующая за ним, интерпретируется как знак «меньше чем». Но пробле- 
мы только начинаются. Даже если бы компилятор, дойдя до двукратно 
вложенного имени оїћһег, каким-то образом мог установить, что геб1па — 
это имя шаблона, он был бы вынужден признать, что это не имя типа! По- 
ра кое-что прояснить. їурейеї должен записываться так: 


Туредег турепаме А: :Тетр1ате геріпа<№ае> : : офпег № деА11ос; 


Ключевое слово {етр1ате дает понять компилятору, что геріпа – это имя 
шаблона, а їурепапе сообщает компилятору, что вся эта ерунда является 
именем типа. Просто, правда? 


Тема 52 | Создание специализации 
для получения информации о типе 


Явная и частичная специализации шаблона класса обычно служат для 
создания версий базового шаблона класса, настроенных под конкретные 
аргументы или классы аргументов шаблона (см. темы 46 «Явная специа- 
лизация шаблона класса» и 47 «Частичная специализация шаблонов»). 


Однако эти возможности языка также широко применяются для обрат- 
ных операций, когда происходит не создание специализации на основа- 
нии свойств типа, а свойства типа логически выводятся из специализа- 
ции. Рассмотрим простой пример: 


Тетр1афе <+урепате Т> 

ѕігисі ІѕІпї // Т не типа іп+... 
{ епит { геѕи1ї = Ға1ѕе }; }; 

Тетр1ате <> 

ѕігисі ІѕІпі<іпі> // если только это іп! 
{ епит { геѕи1ї = гие }; }; 


Прежде чем продолжить, хотелось бы обратить внимание на то, насколь- 
ко прост приведенный выше код (если вы разобрались с его витиеватым 
синтаксисом). Это простой пример метапрограммирования шаблонов, 
т. е. осуществления некоторой части вычислений во время компиляции, 
а не во время выполнения, посредством создания экземпляра шаблона. 
Звучит довольно заумно, но сводится к наблюдению, которое могли бы 
сделать даже мои простодушные соседи, занимающиеся выращиванием 
клюквы: «Это іпі, если это іпі». Самые сложные аспекты программиро- 
вания на С++ с применением шаблонов не сложнее этого, просто они бо- 
лее запутанные. 
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Имея базовый шаблон и полную специализацию, можно спросить (во вре- 
мя компиляции), не является ли неизвестный тип типом іпі: 


Тетр1ате <Турепате Х> 

уоіа аРипс( Х ёаго ) { 
те 
.ІЅІПі<Х>:; ;:геѕи1ї... 
Ае 

} 


Возможность задавать подобные вопросы о типах во время компиляции — 
основа для ряда важных методов оптимизации и контроля ошибок. Ко- 
нечно, информация о том, что какой-то тип точно іпї, на практике не 
очень полезна. А вот знать, что тип является указателем, вероятно, более 
выгодно, поскольку реализации, использующие указатели на объекты 
или непосредственно объекты, отличаются друг от друга: 


ѕігисі Үеѕ {}; // тип, аналогичный гие 
ѕігисі № {}; // тип, аналогичный Ға15е 
(етр1ате <+урепате Т> 
ѕігисЁ ІѕРіг // Т не является указателем. .. 
{ епит { геѕи1ї = Ға1ѕе }; +уреде? № Веѕџ1+; } 
сетр1ате <+урепате Т> 
ѕігисі ІѕРїг<Т *> // если только это неквалифицированный указатель 
{ епит { геѕи1ї = їгие }; уреде? Үеѕ Веѕи1+; } 
сетр1ате <+урепате Т> 
ѕігисі ІѕРіг<Т *сопзї> // или константный указатель, 
{ епит { геѕи1ї = ігие }; уреде? Үеѕ Веѕи1+; } 
сетр1ате <+урепате Т> 
ѕігисі ІѕРіг<Т *\о1а{11е> // или изменяемый указатель, 
{ епит { геѕи1ї = ігџе }; уреде? Үеѕ Веѕи1+; } 
сетр1ате <+урепате Т> 


ѕзігисі ІѕРіг<Т «сопзі у01а{11е> // или константный изменяемый указатель. 
{ епит { геѕи1ї = ігие }; уреде? Үеѕ Веѕи1+; }; 


В случае применения ІѕРїг задается более общий вопрос, чем для І51пї. 
Таким образом, частичная специализация применяется для «выявле- 
ния» по-разному квалифицированных вариантов модификатора указате- 
ля. Как сказано выше, эта возможность Т5Р\г на самом деле не намного 
сложнее для понимания, чем 1511пї. Просто ее синтаксис более запутан- 
ный. (Подобная техника метапрограммирования также приведена в те- 
ме 59 «Концепция 5Е1МАЕ».) 


Чтобы увидеть практическую выгоду от возможности задавать вопросы 
о типе во время компиляции, рассмотрим данную реализацию простого 
шаблона стека: 
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Тетр1афе <+урепате Т> 
с1а5ѕ Ѕіаск { 
рир11с: 
-5+аск(); 
уоіа риѕћ( сопѕі Т ёуа1 ); 
Т &+0р(); 
уоіа рор(); 
6001 етрїу() сопѕї; 
ргіуаїе: 
Ио 
уреде? эта: : едие<Т> С; 
уреде? турепаме С: :1{егафог І 
С; 
}; 


Наш стек – это симпатичный интерфейс-обертка для стандартной очере- 
ди с двумя концами 10906. Аналогичный результат можно было бы полу- 
чить, обратившись к стандартному адаптеру контейнера ѕїаск. Большин- 
ство операций очень просты и могут быть реализованы непосредственно 
с помощью дедие. 


тетр1ате <+урепате Т> 
уоіа Ѕ+аск<Т> : :риѕћ( сопѕї Т &уа1 ) 
{ $ _.риѕћ раск( уа1 ); } 


Но могут возникнуть проблемы с деструктором Ѕїаск. При уничтожении 
Ѕіаск уничтожается и его элемент данных дедие, что, в свою очередь, при- 
ведет к уничтожению всех элементов, остающихся в йедие. Однако если 
эти элементы представляют собой указатели, то объекты, на которые они 
указывают, удалены не будут. Таково поведение стандартного контейне- 
ра децие. Поэтому необходимо выбрать политику уничтожения элементов 
указателей для Ѕїаск, который будет приговорен к уничтожению! (Более 
гибкий подход представлен в теме 56 «Политики».) Мы не можем пору- 
чить уничтожение элементов дедие деструктору, потому что это приведет 
к ошибке в тех случаях, когда элементы не являются указателями. 


Одним из возможных решений могла бы быть частичная специализация 
(базового) шаблона Ѕіаск для обработки стеков указателей (см. тему 47 
«Частичная специализация шаблонов»). Однако это, наверное, чересчур, 
если требуется лишь немного изменить поведение Ѕїаск. Совсем другое де- 
ло просто задавать очевидный вопрос (во время компиляции) и действо- 
вать соответственно ответу: «Если тип элементов, хранящихся в 5їаск, 
представляет собой указатель, то уничтожить все остающиеся элементы. 
В противном случае не уничтожать». 


тетр1ате <+урепате Т> 
с1аѕ5ѕ офаск { 
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рир11с: 
-5+аск() 
{ с1еапир( +урепате ІѕРіг<Т>::Веѕи1ї() ); } 
У н 
ргімаїе: 
уоіа с1еапир( Уез ) { 
Рог( І і( ѕ_.редіп() ); і != ѕ_.өпа(); ++і ) 
де1ете *1 
} 
уоіа с1еапир( № ) 
{} 
уреде? 51а: : дедие<Т> С; 
уреде? турепаме С: :1{егафог І 
Се; 
}; 


Здесь мы имеем две разные функции-члена с1еапир («очистка»), одна из 
которых принимает аргумент типа Үеѕ (Да), тогда как другая принимает 
аргумент типа № (Нет). Версия Үеѕ осуществляет уничтожение; версия 
№ — нет. Деструктор задает вопрос: «Является ли Т указателем? ». Факти- 
чески для этого создается экземпляр І5Ріг с Т, организуется доступ к вло- 
женному имени типа Веѕи1ї (Результат) (см. тему 49 «Устранение неодно- 
значности с помощью ключевого слова їурепате»), которым может быть 
Уез или №, и объект этого типа передается в с1еапир. Будет создан и вы- 
зван экземпляр только одной из двух версий с1еапир (см. тему 61 «Мы соз- 
даем экземпляр того, что используем»). 


Этаск<ЭПаре *> ѕһареѕ; // будет уничтожать 
Ѕъаск<ѕ+1а: : ѕігіпо> патеѕ; // не будет уничтожать 


Специализации шаблонов классов могут служить для извлечения из типов 
информации любого уровня сложности. Например, может понадобиться 
знать не только о том, является ли определенный тип массивом, но и, если 
это массив, какие элементы в нем хранятся и каков его размер: 


Тетр1афе <+урепате Т> 
ѕігисі ІѕАггау { // Т не является массивом. . 
епит { геѕи1+ = Ға1ѕе }; 
уреде? № Веѕи1ї; 
}; 
Тетр1ате <Турепате Е, іп? р> 
ѕігисі ТзАггау<Е [0]> { // ...если только он массив 
епит { геѕи1+ = {гие }; 
Туредег Уез Вези1т; 
епит { Боипа = 0 }; // граница массива 
уреде? Е Ефуре; // тип элемента массива 
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Может понадобиться информация не только о том, является ли опреде- 
ленный тип указателем на данные-член, но и, если это так, имена типов 
класса и члена, на которые он указывает: 


Тетр1афе <+урепате Т> 
ѕігисі ІЅРСМ { // Т не является указателем на данные-член 
епит { геѕи1ї = Ға1ѕе }; 
Туреде? № Веѕи1ї; 
}; 
Тетр1ате <с1а55 С, Турепаме Т> 
ѕігисі ІѕРСМ<Т С::*> { //...если он является! 
епит { геѕи1ї = {гие }; 
Туредег Үеѕ Вези1т; 
Туреде! С С1аѕѕТуре; // класс 
уреде? Т МетрегТуре, // тип члена класса 


}; 


Эти методики применяются во многих популярных инструментальных 
средствах, предоставляющих возможность доступа к свойствам типа 
(см. тему 54 «Свойства») для настройки кода во время компиляции. 


Тема 53 | встроенная информация о типе 


Как узнать тип элементов контейнера? 


Тетр1афе <+урепате Т> 
с1аѕѕ 509 { 

И 
|. 


На первый взгляд это совсем нетрудно. Элемент 5е4<$14: :31г1п9> относит- 
ся к типу $19: :5їгіпо, правильно? Необязательно. При реализации (не- 
стандартного) контейнера последовательности ему ничто не мешает иметь 
тип сопѕЇ Т, Т*х или «умный указатель на Т». (Какой-нибудь особенно за- 
мысловатый контейнер мог бы просто игнорировать параметр шаблона и 
всегда задавать для элемента тип \014 *!) Но капризы реализации не един- 
ственная причина, мешающая определить тип элемента контейнера. Час- 
то создается универсальный код, в котором эта информация просто недо- 
ступна. 


Тетр1ате <с1аз$ Сопіаіпег> 
Е1ет ргосезз( Сопаіпег &с, іпї 317е ) { 
Тетр +етр = Еїет(); 
Ғог( іп і = 0; 1 < $176; ++і ) 
тетр += с[1]; 
гетигп +етр; 


} 


В приведенном выше универсальном алгоритме ргосезз требуется знать 
тип элемента (Е]ет) контейнера (Сопіаіпег), а также тип, который мог бы 
служить для объявления временного хранилища объектов типа элемента 
(Тетр). Но эта информация недоступна, пока не создан экземпляр шабло- 
на функции ргосез$ с определенным контейнером. 
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Обычный выход из данной ситуации – заставить тип предоставить «лич- 
ную» информацию о себе. Такая информация обычно встраивается в сам 
тип. Это напоминает внедрение микрочипа в человека, с которого можно 
считать данные об его имени, идентификационном номере, группе крови 
ит. д. (Это лишь аналогия, а не оправдание подобных вещей.) Нас не ин- 
тересует группа крови последовательности, но необходимо знать тип ее 
элементов. 


ТетрТате <с1аз$ Т> 
с1аѕѕ 509 { 
рир11с: 
уреде? Т Е1ет; // тип элемента 
уреде? Т Темтр; // тип временного хранилища 
ѕіғе і $17е() сопѕї; 
Иа 
}; 


Эту встроенную информацию можно запросить во время компиляции: 


уреде? 5ед4<5+1а: :51гіпо> 51гіпдѕ; 


те 
51г1п95::Е1ет аЅїгіпо; 


Такой подход знаком любому пользователю стандартной библиотеки кон- 
тейнеров. Например, чтобы объявить итератор для стандартного контей- 
нера, рекомендуется узнать у самого контейнера тип его итератора: 


уесіог<іпі> а\ес; 


Е 
Тог( муестог<1пі>::іїегаїтог 1( амес. редіп() ); 
1 != амес.епа(); ++1 ) 


(И... 


Здесь мы не предполагаем, что типом итератора является іпі * (как это 
часто бывает во многих реализациях), а просим уесїог<іпі> сообщить тип 
своего итератора. Типом итератора для уесїог<іпі> может быть любой 
другой тип (например, пользовательский безопасный тип указателя). Та- 
ким образом, единственный способ написать переносимый цикл - полу- 
чить тип итератора от самого уесіог<іпі>. 


Более важное наблюдение – данный подход позволяет писать универсаль- 
ный код, делающий предположение о наличии требуемой информации. 


Тетр1ате <с1аз$ Сопіаіпег> 
+урепате Сопёаіпег: : Е1ет ргосеѕѕ( Соп+аіпег &с, іпї ѕіхе ) { 
Турепате Соптаіпег: : Тетр Тетр 
= їурепате Соптаіпег: : Е1ет(); 
Ғог( іп і = 0; 1 < $176; ++і ) 
тетр += с[1]; 
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гефигп Тетр; 


} 


Эта версия алгоритма ргосеѕѕ запрашивает у типа Сопіаіпег его личные 
данные и предполагает, что Сопта1пег определяет вложенные имена типов 
Е]ет и Тептр. (Три ключевых слова Турепате явно указывают компилятору 
на то, что вложенные имена - это имена типов, а не какие-то другие вло- 
женные имена. См. тему 49 «Устранение неоднозначности с помощью 
имени типа».) 


5$1г110$ 51гіпо$; 
а$їігіпо = ргосез$( ѕїгіпоѕ, ѕїгіпоѕ. $17е() ); // ОК 


Алгоритм ргосеѕѕ хорошо работает с контейнером 5е4 и будет работать 
с любым другим контейнером, соблюдающим наше соглашение. 


Тетр1афе <+урепате Т> 
с1аѕѕ ВЁеайоп1уЅед { 
рир11с: 
уреде? сопѕї Т Е1еп; 
уреде? Т Тетр; 
Иан 
}; 


Мы можем применить ргосез$ к контейнеру Веадоп1узеа, потому что он 
удовлетворяет нашим предположениям. 
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Иногда недостаточно знать тип объекта. Часто существует связанная 
с типом объекта информация, исключительно важная для работы с объ- 
ектом. В теме 53 «Встроенная информация о типе» было показано, что 
такие сложные типы, как стандартные контейнеры, часто содержат 
встроенную информацию о себе: 


51г1іпдѕ 5110$; 

а$ігіпо = ргосеѕѕ( 31г1п9$, ѕігіподѕ. ѕіхе() ); // ок 
51а: : месфог<$4: :$г119> ѕ1гіпоѕ2; 

а$їгіпо = ргосез$( ѕїгіпдѕ2, ѕігіпд52.517е() ); // ошибка! 


ехтегп доир1е геад1паз[В$Т7]; 
доир1е г = ргосеѕѕ( геайіпоѕ, В5Т7 ); // ошибка! 


Алгоритм ргосеѕѕ эффективен в случае контейнера 5е4, но не годится для 
стандартного контейнера \естог, потому что уестог не определяет вложен- 
ные имена типов, существование которых предполагает ргосез$. 


Алгоритм ргосеѕѕ может применяться к контейнеру Веайоп1у$ед, потому 
что он удовлетворяет нашим предположениям. Но может понадобиться 
применить ргосез$ к контейнерам, не следующим этому довольно узкому 
соглашению, или к «контейнероподобным» объектам, даже не являю- 
щимся классами. Часто для решения этих проблем привлекаются классы 
свойств (ітаііѕ 4аззез). 


Класс свойств — это коллекция информации о типе. Однако в отличие от 
вложенной информации контейнера, класс свойств не зависит от типа, 
который описывает. 


Тетр1ате <Турепате Сопї> 
ѕігисі СоптаіпегТгаіїѕ; 
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Классы свойств широко применяются для размещения отвечающего со- 
глашению слоя между универсальными алгоритмами и типами, которые 
не следуют соглашению. Алгоритм создан с учетом особенностей типа. 
Общий случай всегда предполагает наличие какого-то соглашения. 
В данном случае СопіаіпегТгаіїѕ принимает соглашение, используемое 
контейнерами 5ед и Аеайоп1уЅед. 


Тетр1ате <Турепате Сопї> 

ѕігис СопаіпегТгаіїѕ { 
уреде? турепаме Соп: :Е1ет Е1ет; 
Туреде# +урепате Сопт: :Тетр Тетр 
Туреде# +урепате Соп: : Рг Ріг 

}; 


С введением этого шаблона класса свойств появляется выбор. Ссылаться 
на вложенный тип Е1еп одного из наших типов контейнеров теперь можно 
или через тип контейнера, или через экземпляр типа свойств, созданный 
для типа контейнера. 


уреде? Ѕед<іпї> Сопї; 
Соп: :Е1ет е1 
СопіаіпегТгаіїѕ<Сопі>: :Е1ет е2; // того же типа, что и е1 


Наш универсальный алгоритм можно переписать с использованием 
свойств вместо прямого доступа к именам вложенных типов контейнера: 


Тетр1ате <Турепате Соптаіпег> 
Турепате СоптаіпегТгаіїѕ<Сопіаіпег>: : Еет 
ргосеѕѕ( Сопаіпег &с, іпї 317е ) { 
Турепате СоптаіпегТгаіїѕ<Соптаіпег>: : Тепр ёетр 
= Турепаме СоптаіпегТгаіїѕ<Сопіаіпег> : : Е1ет(); 
Ғог( іп і = 0; 1 < $176; ++і ) 
фетр += с[ 1]; гефигп +етр 
} 


Может показаться, что мы лишь усложнили синтаксис универсального 
алгоритма ргосеѕѕ! Ранее, чтобы получить тип элемента контейнера, мы 
записывали Турепате Сопта1пег: : Е1ет. В переводе на обычный язык это 
означает: «Получи вложенное имя Е!еп контейнера Сопіаіпег. Кстати, это 
имя типа». С классами свойств приходится записывать фурепате Сопїаіпег- 
Тгаіїѕ<Сопїаіпег>: : Е тет. Это означает: «Создай экземпляр класса Сопїаіпег- 
Тгаіїѕ, соответствующего этому контейнеру, и получи его вложенное имя 
Еет. Кстати, это имя типа». Сделан шаг назад – мы получаем информа- 
цию не от типа контейнера непосредственно, а от посредника, в виде клас- 
са свойств. Если доступ к вложенной информации типа рассматривать как 
считывание информации о человеке со встроенного микрочипа, то исполь- 
зование класса свойств аналогично поиску информации о ком-то в базе 
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данных с применением имени человека в качестве ключа. В результате 
получаем одну и ту же информацию, но поиск в базе данных, конечно, 
менее агрессивный и более гибкий. 


Например, нельзя получить информацию с микрочипа, если его нет. 
(Возможно, человек прибыл из региона, где встроенные микрочипы но- 
сить не обязательно.) Однако для такого человека всегда можно создать 
новую запись в базе данных, даже не проинформировав его об этом. Точно 
так же можно специализировать птаблон свойств, чтобы он предоставлял 
информацию о конкретном не соответствующем соглашениям контейне- 
ре, не касаясь самого контейнера: 


с1аѕѕ РогеідпСоп+аіпег { 
// нет вложенной информации типа... 
у; 
//... 
Тетр1ате <> 
ѕігисї СоптаіпегТгаіїѕ<ҒогеідпСоп+аіпег> { 
уреде? іпї Ееп; 
Туредег Еет Тетр; 
Туредег Еет *Ріг; 
у; 
Имея в распоряжении специализацию СопїаіпегТгаіїѕ, можно применять 
алгоритм ргосеѕѕ к Гоге1дпСопта1пег так же эффективно, как к контейнеру, 
написанному в соответствии с нашим соглашением. Первоначальная реа- 
лизация ргосеѕѕ в применении к РогеідпСопїаіпег даст сбой, потому что по- 
пытается получить доступ к несуществующей вложенной информации: 


РогеідпСоптаіпег: : Е1епт х; // ошибка, нет такого вложенного имени! 


СоптаіпегТгаіїѕ<Ғогеіопбопаіпег>: ;Е1ет у; // ОК, использование свойств 


Полезно рассматривать шаблон свойств как коллекцию информации, ин- 
дексированную типом, по аналогии с ассоциативным контейнером, ин- 
дексированным ключом. Но «индексация» свойств происходит во время 
компиляции через специализацию шаблона. 


Другое преимущество доступа к информации о типе через класс свойств 
в том, что эта методика может применяться для предоставления инфор- 
мации о типах, не являющихся классами и, следовательно, не имеющих 
вложенной информации. Даже несмотря на то, что классы свойств явля- 
ются классами, типы, свойства которых они инкапсулируют, не обязаны 
быть таковыми. Например, массив – это своего рода (математически или 
фактически) вырожденный контейнер, с которым можно работать как 
с обычным контейнером. 


Тетріаїте <> 
ѕігисі Соп+аіпегТгаіїѕ<сопѕї сһаг *> { 
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Туредег сопѕї спаг Е1ем; 

ТуредеГг спаг Тетр; 

Туредег сопѕї спаг х*Рфг; 
}; 


Имея в распоряжении эту специализацию для «контейнера» типа сопз+ 
сһаг *, можно применять ргосеѕѕ к массиву символов. 


сопѕі сһаг *пате = "Агѕепе [ир1п”; 
сопѕі сһаг *г = ргосеѕѕ( пате, ѕіг1еп(паме) ); 


Можно продолжать в том же духе для других типов массивов, создавая 
специализации для 111 *, сопѕї доц] е * ит. д. Однако было бы удобнее оп- 
ределить один вариант для любого типа указателей, поскольку все они 
будут иметь общие свойства. Этой цели служит частичная специализация 
шаблона свойств для указателей: 


Тетр1афе <+урепате Т> 

зїгисї СопаіпегТгаіїѕ<Т *> { 
уреде? Т Ееп; 
уреде? Т Тетр; 
уреде? Т «Рег; 

|: 


Специализация СопїіаіпегТгаіїѕ для любого типа указателя, будь то іпі * 
или сопѕЇ Ё1оаї *(*сопѕї *) (іпї), приведет к созданию экземпляра этой час- 
тичной специализации, если только не доступна еще более специализиро- 
ванная версия СопїаіпегТгаіїѕ. 


ехфегп доир1е геадіпоѕ[ А512]; 
аоир1е г = ргосеѕѕ( геадіпоѕ, ВЅ17 ); // работает! 


Однако это еще не все. Обратите внимание, что в случае частичной специа- 
лизации для указателя на константу будет неправильно выбран «времен- 
ный» тип. То есть константные временные значения не имеют особого 
практического значения, потому что для них нельзя осуществить опера- 
цию присваивания. Желательно было бы иметь в качестве временного ти- 
па неконстантный аналог типа элемента. В случае с сопѕї спаг *, например, 
СоптаіпегТгаіїѕ<сопї спаг *>: : Тепр должен иметь тип спаг, а не сопѕї спаг. 
Выйти из этой ситуации можно с помощью частичной специализации. 


Тетр1ате <Турепате Т> 

ѕігисі СоптаіпегТгаіїѕ<сопѕї Т => { 
уреде? сопѕї Т Е1еп; 
уреде? Т Тетр; // примечание: неконстантный аналог Е1ет 
Туреде? сопѕї Т *Рїг; 

}; 
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Эта более специализированная частичная специализация будет предпоч- 
тительнее предыдущей в тех случаях, когда аргумент шаблона представ- 
ляет собой указатель на константу, а не указатель на неконстанту. 


Частичная специализация также способна помочь в расширении механиз- 
ма свойств для приведения «чужого» соглашения в соответствие с локаль- 
ным соглашением. Например, ТІ, очень жестко придерживается согла- 
шений (см. тему 4 «Стандартная библиотека шаблонов»), и стандартные 
контейнеры имеют понятия, подобные тем, которые инкапсулирует наш 
СоптаіпегТгаіїѕ, но они иначе представлены. Вернемся к неудачной попыт- 
ке создания экземпляра алгоритма ргосеѕѕ для стандартного \уестог и ис- 
правим ошибки. 


Тетр1ате <с1а55 Т> 
ѕігис СопаіпегТгаіїѕ< $14: :уес+ог<Т> > { 
уреде? турепаме 51а: : хесфтог<Т>: :ма1иџе Туре Ееп; 
туреде# +урепате 
ѕ1а: :ітегаог_ гаіїѕ<Турепате 
51а: :местог<Т>: :іегаїог> 
‘іуа1ие Туре Тетр 
Туреде# +урепате 
Уфа: :ітегаог_ гаіїѕ<Турепате 
51а: :месфог<Т>: : іегаїог> 
гіроіпїег Ріг 


}; 


Это не самая удобочитаемая реализация из тех, которые можно предста- 
вить, но она скрытая, и теперь пользователи могут инициировать наш 
универсальный алгоритм с помощью контейнера, созданного из стан- 
дартного уестог. 


ѕ1а: : местог<$та: :51гіпо> ѕїгіпдѕ2 
а$їгіпо = ргосез$( ѕїгіпоѕ2, ${г1п9$2.$12е() ); // работает! 
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Вернемся к шаблону Ѕїаск, рассматриваемому в теме 52 «Создание специ- 
ализации для получения информации о типе». Он был реализован с при- 
менением стандартного контейнера дедие. Это довольно хороший компро- 
мисс для реализации, хотя во многих случаях более эффективным или 
подходящим мог бы быть другой контейнер. Данную проблему можно ре- 
шить введением в Ѕїаск дополнительного параметра шаблона для типа 
контейнера, задействованного в его реализации. 


Тетр1ате <+урепате Т, с1азз Сопі> 
с1аѕ5 Ѕїаск; 


Для простоты откажемся от стандартной библиотеки (далеко не всегда 
это правильный путь) и предположим, что имеем в своем распоряжении 
ряд нестандартных шаблонов контейнеров: 1 іѕї, Уестог, Вецие и, возмож- 
но, другие. Представим, что эти контейнеры аналогичны стандартным, 
но имеют только один параметр шаблона для типа элемента контейнера. 


Вспомним, что на самом деле у стандартных контейнеров как минимум 
два параметра: тип элемента и тип распределителя. Распределители необ- 
ходимы контейнерам для того, чтобы иметь возможность настраивать 
процессы выделения и высвобождения своей рабочей памяти. Иначе го- 
воря, распределитель определяет политику управления памятью для 
контейнера (см. тему 56 «Политики»). Распределитель имеет значение 
по умолчанию, так что о нем легко забыть. Однако при создании экземп- 
ляра стандартного контейнера, такого как уесїог<іпі>, фактически полу- 
чаем уесїог< іпі, 51а; : а11осатог<іпі> >. 


Например, объявление нестандартного |151 было бы таким: 


Тетр1ате <Турепате> с1аз$ [1$%1; 
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Обратите внимание, что в приведенном выше объявлении |154 пропущено 
имя параметра шаблона. То же самое происходит с именем формального 
аргумента в объявлении функции: задавать имя параметра шаблона в объ- 
явлении шаблона не обязательно. Аналогично с описанием функции: имя 
параметра шаблона требуется только в описании шаблона и только если 
имя параметра фигурирует в шаблоне. Однако, как и для формальных ар- 
гументов в объявлениях функций, в объявлениях шаблонов параметрам 
шаблонов обычно даются имена, чтобы облегчить документирование 
шаблона. 


Тетр1ате <+урепате Т, с1азз Сопі> 
с1аѕѕ Ѕіаск { 
рир1іс: 
-Ѕїаск(); 
уоіа риѕћ( сопѕі Т ё ); 
Иа 


ргімаїе: 
Соп $_; 
}; 


Теперь пользователь Ѕ$їаск должен предоставить два аргумента шаблона — 
тип элемента и тип контейнера, а контейнер должен быть в состоянии 
хранить объекты типа элемента. 


Ѕтаск<іпі, іізѕзїі<іпї> > а$+аскі; // ок 
ЭТаск<аоц61е, 11$Е<1пЕ> > аЅіаск2; // допустимо, но не годится 
Ѕеаск<їа: :ѕїгіпо, редие<сһаг *> > аЅ+аск3; // ошибка! 


В случае аЅтаск2 и аѕїаскзЗ возникают проблемы с согласованностью. Если 
пользователь выбирает неверный тип контейнера для типа элемента, воз- 
никает ошибка компиляции (в случае аЅїаск3 из-за невозможности копи- 
ровать ѕігіпо в сһаг *) или скрытый дефект (в случае аЅаск2 из-за погреш- 
ности при копировании 010001е в 111). Кроме того, большинство пользовате- 
лей Ѕїаск не хотят возиться с выбором базовой реализации и будут удовле- 
творены разумным значением по умолчанию. Ситуацию можно улучшить, 
предоставив значение по умолчанию для второго параметра шаблона: 


Тетр1ате <Турепате Т, с1а55 Сопї = Бедие<Т> > 
с1аѕѕ офаск { 

//... 
}; 


Это помогает, когда пользователь Ѕ$їаск желает принять реализацию 0едие 
или реализация его не особо волнует. 


Ѕъаск<іпї> аЗТаск1; // контейнер = редие<іпї> 
Ѕтаск<ӣоир1е> аЅіаск2; // контейнер = редие<аоир1е> 
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Этот подход приблизительно похож на тот, который используется адапте- 
рами стандартных контейнеров $Таск, дцеце и ргіогіїу диеие. 


$14: зфаск<1пт> 319$; // контейнер - аедие< 11, а110оса+ог<іпї> > 


Здесь мы видим разумный компромисс между удобством случайного ис- 
пользования возможностей Ѕїаск и гибкостью для опытного пользовате- 
ля, которая обеспечивает возможность использования любого (допусти- 
мого и эффективного) контейнера для хранения элементов 5їаск. 


Однако эта гибкость достигается за счет надежности. По-прежнему необ- 
ходимо согласовывать типы элемента и контейнера в других специализа- 
циях, и это требование согласования открывает простор для ошибок. 


Ѕтаск<іпі, іѕїі<іпї> > аѕ+аскз; 
Ѕ+аск<іпї, Гіѕї<ипѕідпей> > аЅаск4; // ой! 


Давайте посмотрим, можно ли увеличить надежность и сохранить при 
этом приемлемую гибкость. Шаблон может принимать параметр, сам яв- 
ляющийся именем шаблона. Эти параметры имеют замечательное назва- 
ние – параметры-шаблоны шаблона (+етріаїе їетріаїе рататеїегз). 


тетр1ате <+урепате Т, Тетр1афе <+урепате> с1аз$ Сопї> 
с1аѕ5 Ѕіаск; 


При виде этого нового списка параметров шаблона для класса Ѕїаск про- 
сто опускаются руки, но все не так плохо, как кажется. Первый пара- 
метр, Т, был здесь и раньше. Это просто имя типа. Второй параметр, 
Сопі — параметр-шаблон шаблона. Это имя шаблона класса с одним пара- 
метром – именем типа. Заметьте, что для параметра имени типа (опі имя 
не задано, хотя это можно было бы сделать: 


Тетр1афе <+урепате Т, Тетр1афе <+урепате Е1етепЕТуре> с1аѕѕ Сопі> 
с1аѕ5 Ѕіаск; 


Однако такое имя (Е1етепїТуре (Тип элемента)) может играть только ин- 
формативную роль как имя формального аргумента в объявлении функ- 
ции. Обычно эти имена опускаются, но могут свободно использоваться 
везде, где улучшают читаемость кода. Наоборот, можно было бы восполь- 
зоваться возможностью и снизить читаемость до минимума, исключив из 
объявления $їаск все необязательные с технической точки зрения имена: 


Тетр1ате <Турепате, Тетр1афе <+урепате> с1аѕ5> 
с1аѕ5 Ѕіаск; 


Но из сочувствия к тем, кому придется читать код, надо избегать такой 
практики, даже несмотря на то, что язык С++ позволяет делать это. 
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Шаблон Ѕ+іаск использует свой параметр имени типа для создания экземп- 
ляра параметра-шаблона. Получающийся в результате тип контейнера 
служит для реализации Ѕїаск: 


Тетр]ате <+урепате Т, Тетр1афе <+урепате> с1аѕѕ Сопф> с1аѕѕ ЭТаск { 


Иа. 
ргімаїе: 
Сопі<Т> $; 
}; 


При таком подходе согласование элемента и контейнера может осуществ- 
ляться самой реализацией біаск, а не кодом, специализирующим $іаск. 
Но этот момент специализации сокращает возможность ошибки при со- 
гласовании типа элемента и контейнера, служащего для хранения эле- 
ментов. 


Ѕтаск<іпі, 11ѕ1> абфаск1; 
Ѕтаск<5+1а: : $Ег1па, Ведие> аЅтаск2; 


Для дополнительного удобства можно использовать значение по умолча- 
нию аргумента-шаблона шаблона: 


тетр1ате <+урепате Т, ТетрТафе <+урепате> с1аз$ Сопї = Ведие> 
с1аѕѕ Ѕіаск { 
МЕ 

}; 

И 

Ѕбтаск<іпї> аЅ+аск1; // используется значение по умолчанию: 
// Соп является редие 

Ѕіаск<5+1а: : ѕігіпо, [1$Е> аѕ+аск2; // Сопі является 11ѕї 


Обычно этот подход хорош для согласования набора аргументов шаблона 
и шаблона, экземпляр которого должен быть создан с участием этих аргу- 
ментов. 


Часто параметры-шаблоны путают с параметрами имени типа, которые 
по чистой случайности генерируются из шаблонов. Рассмотрим следую- 
щее объявление шаблона класса: 


Тетр1афе <с1аѕѕ Сопі> с1аѕѕ Мгаррегі; 


Шаблон Мгаррег1 (Обертка1) принимает имя типа в качестве аргумента 
шаблона. (В объявлении параметра Сопї шаблона \гаррег1 вместо ключе- 
вого слова Турепате используется ключевое слово с1а55, чтобы сообщить 
читателям о том, что здесь ожидается с1аз$ или ѕїгисї, а не произвольный 
тип. Хотя компилятору все равно. В данном контексте технически Ту- 
репате и с1аз$ означают абсолютно одно и то же. См. тему 63 «Необяза- 
тельные ключевые слова».) Это имя типа могло бы быть сгенерировано из 
шаблона, как в М№гаррег1<1151<іпї>>, но 1151<іпі> по-прежнему остается 
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всего лишь именем класса, даже несмотря на то, что был сгенерирован из 
шаблона. 


Мгаррег1< Г1іѕї<іпі> > м1; // хорошо, Сіѕї<іпї> - имя типа 
Мгаррег1< ѕіа::1іѕ1<іпї> > м2; // хорошо, 1іѕї<іпі> - тип 
Мгаррег1<Е1$12> м3; // ошибка! 1151 - имя шаблона 


В качестве альтернативы рассмотрим следующее объявление шаблона 
класса: 


Тетр1ате <+етр1аїе <Турепате> с1азз Сопї> с1аѕѕ Мгаррег2; 


Шаблону Мгаррег2 требуется имя шаблона как аргумент шаблона, и не 
просто имя шаблона. Объявление гласит, что шаблон должен принимать 
один аргумент имени типа. 


Мгаррег2<Е1$1> м4; // хорошо, 11$ - шаблон с одним аргументом 
Мгаррег2< 1іѕі<іпї> > м5; // ошибка! іѕї<іпі> не шаблон 
Мгаррег2<319: :1151> мб; // ошибка! 314: :11$ принимает два 


// и более аргументов 


Если мы хотим иметь шанс создавать специализации со стандартным 
контейнером, необходимо сделать следующее: 


Тетр1ате <тетр1афе <Турепате Е1ептеп?, 
с1аѕѕ А110саїог> с1аѕѕ Сопі> 
с1а55 МгаррегЗ; 


или, что равнозначно: 


Тетр1ате <Тептр1ате <Турепате, Турепате> с1аз$ Сопї> 
с1а55 МгаррегЗ; 


Это объявление говорит о том, что шаблон должен принимать два аргу- 
мента имени типа: 


№гаррегЗ<+а: :1151> м7; // может работать... 
МгаррегЗ< 510: :1151<іпі> > м8; // ошибка! 1іѕі<іпі> - это класс 
№гаррегз<іѕі> м9; // ошибка! [135% принимает один аргумент имени типа 


Однако для шаблонов стандартных контейнеров (таких, как этот) допус- 
кается объявление более двух параметров, так что приведенное выше 
объявление \7 на некоторых платформах может не работать. Да, мы все 
любим и уважаем ТІ, но никогда не утверждали, что она идеальна. 


Тема 56 | Политики 


В теме 52 «Создание специализации для получения информации о типе» 
был спроектирован шаблон стека, который удалял все элементы, остаю- 
щиеся в нем в конце существования, если типом элементов стека был ука- 
затель. 


Тетр1ате <+урепате Т> с1аѕ5 Ѕіаск 


Такая политика не лишена здравого смысла, но ей не хватает гибкости. 
Возможны ситуации, когда пользователь не хочет удалять то, на что ссы- 
лаются указатели стека. Например, указатели могут ссылаться на объек- 
ты, не находящиеся в куче или используемые совместно с другими кон- 
тейнерами. Кроме того, указатель может ссылаться на массив объектов, 
а не на одиночный объект. Если имеется стек указателей на символы, 
практически со стопроцентной уверенностью можно сказать, что так оно 
и есть, потому что указатели символов обычно ссылаются на МТСТВ (паП 
фегтшафе4 аггау оѓ сһагасіегѕ — массивы символов, завершающиеся сим- 
волом пи11): 


Эфаск<сопзЕ сһаг *> паптеѕ; // ой! неопределенное поведение 


Наша политика уничтожения предполагает, что указатели Ѕіаск ссыла- 
ются на одиночный объект, и, следовательно, использует форму операто- 
ра йе1еїе, предназначенную для удаления одиночных объектов, тогда как 
для массива должна применяться специальная форма оператора йе10еїе: 
орега+ог де1етїе[ ] (см. тему 37 «Создание массивов»). 


Наша цель – суметь написать примерно такой деструктор шаблона Ѕїаск: 


тетр1ате <+урепате Т> 
с1аѕѕ Ѕіаск { 
рир11с: 


192 Тема 56 


-Ѕ+аск() { 
Ғог( І і( з. редіп() ); і != $_.еп9(); ++1 ) 
адоре1е+іопРо11їсу( *1 ); 
} 
И 


ргтуате: 
Туредег $194: :Чедие<Т> С; 
уреде? турепаме С: :1%егафог І 
5: 
}; 


Деструктор перебирает все оставшиеся элементы и применяет предусмот- 
ренную для каждого элемента политику уничтожения. Функцию 000е1е- 
{10пР011су (примени политику уничтожения) можно реализовать по-раз- 
ному. Обычно политика задается явно при создании экземпляра шаблона 
Ѕїаск и реализуется параметром-шаблоном шаблона (см. тему 55 «Пара- 
метры-шаблоны шаблона»). 


Тетр1ате <+урепате Т, Тетр1афе <+урепате> с1азз Бе1е{1опРо11су> 
с1аѕ5 Эфаск { 
рир11с: 
-5+аск() { 
Рог( І і( ѕ_.редіп() ); 1 != ѕ_.өпа(); ++і ) 
Ое1е{1опРо11су<Т>: : йоре1ете( *1 ); // выполняется политика 
} 
он 


ргіуате: 
уреде? ѕїа: :Чедие<Т> С; 
уреде? турепаме С: :1{егафог І 
сз; 
}; 


Рассмотрев применение политики уничтожения в деструкторе Ѕіаск, 
можно установить, что политика уничтожения Ѕїаск – это шаблон класса, 
экземпляр которого создается вместе с типом элемента Ѕїаск. Имеется 
статическая функция-член 900е1ете, осуществляющая соответствующее 
действие по уничтожению элемента Ѕїаск. Теперь можно приступить 
к определению некоторых необходимых политик. Одна из них – полити- 
ка уничтожения: 


Тетр1афе <+урепате Т> 
ѕігис Регре1е+еРо1ісу { 
ѕъаїіс уоіа доре1еїе( Т рїг ) 
{ де1еїе рїг; } 
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Конечно, можно было бы реализовать политику с помощью другого ин- 
терфейса. Например, можно было бы обойтись без статической функции, 
а перегрузить оператор вызова функции: 


Тетр1ате <турепате Т> 
ѕігисі Рігре1е+еРо1ісу { 
уоіа орегаїог ()( Т ріг ) 
{ де1еїе ріг; } 
| 


и изменить операцию уничтожения в деструкторе Ѕ5їаск 
ре1еііопРо1ісу<Т>() (+1) 


Важно установить соглашение, требующее, чтобы доступ к реализации 
каждой политики осуществлялся с использованием одного и того же син- 
таксиса. 


Другие полезные политики выполняют уничтожение массивов или вооб- 
ще ничего не делают: 


тетр1ате <+урепате Т> 

ѕігисі Аггауре1е+еРо1ісу { 

ѕ+ъаїіс уоіа доре1еїе( Т рїг ) 

4 де1еїе [1] ріг; } 

}; 

тетр1ате <+урепате Т> 

ѕігис №оре1е+еРо1ісу { 

ѕаїіс уоіа аоре1еіе( сопѕі Т ё ) 
{} 


}; 


Теперь при создании экземпляра Ѕіаск можно задать соответствующую 
политику уничтожения: 


Ѕъаск<іпї, М№оре1етеРо11су> $1; // не удалять элементы типа іпї 
Ѕ+аск<5+а: ;ѕігіпо *, РЕгре1етеРо1ісу> $2; // удалять элементы типа ѕігіпо * 
Ѕ+аск<сопѕї сһаг *, Аггауде1етерРо11су> $3; // использовать йе1еїе [] 
Ѕ+ъаск<сопѕї сһаг *, М№ре1етеРо11су> 54; // не удалять! 

Ѕёаск<іпї, Рігре1етеРо1ісу> $5; // ошибка! не может удалять элемент типа іпї! 


Если одна политика применяется чаще других, то ее и надо сделать поли- 
тикой по умолчанию: 


Тетр1ате <+урепапе Т, 
Тетр1ате <+урепате> с1аѕѕ Ве1еїіопРо1ісу = Мобе1етеРо11су> 
с1аѕѕ Ѕіаск; 


А 
Ѕтаск<іпї> 56; // не уничтожать 
Ѕтаск<сопѕї сһаг *> 97; // не уничтожать 


Ѕъаск<сопѕі сһаг *, Аггауде1етерРо11су> 58; // де1еїе [] 
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Конструкция шаблона обычно предлагает несколько возможностей пара- 
метризации через политики. Например, в теме 55 «Параметры-шаблоны 
шаблона» пользователю была предоставлена возможность задавать спо- 
соб реализации Ѕіаск. Это политика реализации: 


Тетр]1ате <+урепапе Т, 
Тетр1ате <Турепате> с1аѕѕ Ве1ІеїіопРо1ісу = М№ре1етеРо1ісу 
Тетр1а+е <+урепате> с1аѕѕ Сопї = редие> 

аѕѕ Ѕтаск; 


о 


Политика реализации дает пользователю З{аск дополнительную гибкость: 


(Єр) 


саск<аӢоир1е *, Аггауре1етеРо1ісу, Местог> даі1уВеадіпоѕ; 


обеспечивая при этом хорошее общее поведение по умолчанию. 


Ѕтаск<ӣоир1е> тогеВеад1п93; // нет уничтожения, используйте редие 


В универсальном проектировании обычно принимаются решения о поли- 
тике реализации и поведения. Часто эти решения можно вынести и пред- 
ставить как политики. 


Тема 57 | Логический вывод аргументов 
шаблона 


Шаблоны классов должны специализироваться явно. Например, при спе- 
циализации контейнера Неар, обсуждаемого в теме 46 «Явная спеииали- 
зация шаблона класса», необходимо предоставить шаблону аргумент, за- 
дающий тип: 


Неар<іпі> аНеар; 
Неар<соп${ сһаг *> апоїћегНеар; 


Шаблоны функций также могут специализироваться явно. Предполо- 
жим, имеется шаблон функции, осуществляющий ограниченное приве- 
дение в старом стиле: 


Тетр]1ате <Турепапте В, Турепате Е> 

В саѕі( сопзЕ Е &ехрг ) { 
// ...проводится интеллектуальная проверка. .. 
гетигп В( ехрг ); //...и приведение. 

} 


Провести специализацию этого шаблона можно явно при его вызове, точ- 
но так же, как должен специализироваться шаблон класса: 


іпі а = саѕї<іпі, 90и61е>(12.3); 


Однако обычно удобнее позволить компилятору вывести аргументы шаб- 
лона из типов аргументов (фактических параметров) вызова функции. 
Ничего удивительного, этот процесс называется логическим выводом ар- 
гументов шаблона. Будьте осторожны! В приведенном ниже описании 
обратите внимание на разницу между терминами «аргумент шаблона» и 
«аргумент функции» (см. тему 45 «Терминология шаблонов»). Рассмот- 
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рим пример содним аргументом шаблона, выявляющий меньший из 
двух аргументов функции. 


Тетр1афе <+урепате Т> 
Т тіп( сопѕї Т &а, сопѕі Т ёр ) 
{ геїигпа<р?а : б; } 


Когда піп используется без явного предоставления аргументов шаблона, 
компилятор проверяет типы аргументов вызова функции, чтобы логиче- 
ски вывести аргумент шаблона: 


іпі а = тіп( 12, 13 ); // Т является іпі 
оир1е а = тіп( '\0', '\а’); // Т является сһаг 
сһаг с = піп( 12.3, 4 ); // ошибка! Т не может быть одновременно 


// и ӣоир1е, и іпї 


Приведенная выше строка с ошибкой является результатом неспособно- 
сти компилятора вывести аргумент шаблона в ситуации неоднозначно- 
сти. В подобных случаях всегда есть возможность задать аргумент шабло- 
на явно: 


Ч = міп<ӣоир1е>( 12.3, 4); // ОК, Т является йоир1е 


Аналогичная ситуация возникает и с шаблоном саз{, если попытаться ис- 
пользовать логический вывод аргумента шаблона: 


поа = сав 12930): // ошибка! Е - доир1е, но чем является А? 


Как и при разрешении перегрузки, при логическом выводе аргументов 
шаблона компилятор проверяет только типы аргументов функции, но не 
предполагаемые возвращаемые типы. Компилятор может узнать возвра- 
щаемый тип, только если мы сообщим его: 


іпї а = саѕї<іпї>( 12.3 ); // Е - доир1е, А - іпї (задан явно) 


Обратите внимание, что все прослеживаемые аргументы шаблона могут 
не включаться в список аргументов шаблона, если компилятор может ло- 
гически вывести их. В данном случае компилятору был предоставлен 
только возвращаемый тип, а тип выражения он определил самостоятель- 
но. Огромное значение для удобства в работе имеет порядок параметров 
шаблона, поскольку, если бы тип выражения предшествовал возвращае- 
мому типу, пришлось бы задавать явно оба. 


Здесь многие читатели обратят внимание на синтаксис приведенного вы- 
ше вызова функции саѕії и спросят: «Вы подразумеваете, что ѕіаііс саѕї, 
Яупатіс_саѕі, сопзі саѕї и геіпіегргеї саѕї являются шаблонами функ- 
ций?». Нет, мы не делаем такого предположения, потому что эти четыре 
оператора приведения не шаблоны, а встроенные операторы (как опера- 
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торы пем или оператор + для операций над целыми). Но, несомненно, вы- 
глядит так, как будто их синтаксис испытал влияние шаблона функции 
саѕї. (См. тему 9 «Новые операторы приведения».) 


Обратите внимание, что логический вывод аргументов шаблона осущест- 
вляется путем проверки типов фактических параметров вызова. Тем са- 
мым подразумевается, что любой аргумент шаблона функции, который 
не может быть логически выведен из типов аргументов, должен задавать- 
ся явно. Например, вот шаблон функции, обеспечивающий надоедливые 
повторы: 


Тетр1афе <іпї п, +урепате Т> 
уоіа гереаї( сопѕі Т &т59 ) { 
Тог( іпі і = 0; 1 < п; ++1 ) 
ѕ1а: :соиї << тѕо << 51а: : 131; 
} 


Здесь все сделано аккуратно и аргумент шаблона типа іпі помещен перед 
аргументом типа. Поэтому можно было обойтись заданием только числа 
повторов сообщения и позволить установить тип сообщения путем логи- 
ческого вывода аргументов птаблона: 


гереаї<12>( 42 ); // п = это 12, Т - это іпі 
гереаї<МАХІМТ>( '\а’); // п - это очень много, Т - это сһаг 


В шаблонах саѕї, піп, и гереаї компилятор выводит единственный аргу- 
мент шаблона из единственного аргумента функции. Однако механизм 
логического вывода способен находить несколько аргументов шаблона из 
типа единственного аргумента функции: 


Тетр1ате <іпї боипа, Турепаме Т> 
уоіа ғего0иї( Т (вагу) [ооџпа] ) { 

Рог( іпі і = 0; і < броџпа; ++і ) 

агу[1] = Т(); 

} 
И 
Ссоп5ї іпі һгѕіпмеек = 7 х 24; 
Ғ1оаі геадіпоѕ[ һгѕіпмеек ]; 
тегобиї( геааіпоѕ ); // Боип@ == 168, Т является Ғ1оаї 


В данном случае гего0иї ожидает в качестве аргумента массив, и меха- 
низм логического вывода аргументов может провести анализ типа аргу- 
мента и установить границу и тип элементов массива. 


В начале этой темы отмечалось, что специализация шаблона класса 
должна проводиться явно. Однако логический вывод аргументов шабло- 
на функции может использоваться для косвенной специализации шабло- 
на класса. Рассмотрим шаблон класса, с помощью которого можно гене- 
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рировать объект-функцию из указателя функции (см. тему 20 «Объекты- 
функции 5ТГ»): 


Тетр1ате <Турепате А1, Турепаме А2, Турепаме В> 
с1аѕѕ РЕџп2 : рир1іс ѕїа: : ріпагу_ Ғипстіоп<А1, А2, В> { 
рир11с: 
ехр1ісії РЕџп2( В (*#р)(А1,А2) ) : (р) {} 
В орега+ог() ( А1 а1, А2 а2 ) сопѕі 
{ геигп Рр_( а1, а2 );} 
ргіуаїе: 
В (*Гр_) (АТ, А2); 
}; 


(Это упрощенный вариант стандартного шаблона роіпіег_ їо бріпагу_Ғипс- 
їјоп (указатель на бинарную функцию). Он был выбран из-за запутанного 
синтаксиса его специализации. Хуже не бывает.) Создать экземпляр шаб- 
лона напрямую нелегко: 


6001 іѕбгеа+ег( іпі, 111 ); 
ѕіа: :ѕогі(0, е, РЕип2<іпї, іп, 6001>(1$@геатег)); // болезненно 


В подобных случаях принято предоставлять вспомогательную функцию 
(перег Рипсііоп), единственным назначением которой является логиче- 
ский вывод аргументов шаблона с целью автоматической специализации 
шаблона класса: 


Тетр1ате <Турепате В, Турепате А1, Турепате А2> 

іп1іпе РЕџп2<А1, А2, А> такеРЕип( ВА (=*р+#) (А1, А2) ) 
{ гетигп РЕџп2<А1, А2, А>(р#); } 

Г 


ѕіа: :ѕогі(ь, е, макеРЕип(іѕбгеа+ег)); // намного лучше. .. 


В этой демонстрации силы логического вывода компилятор может вывес- 
ти типы обоих аргументов, и возвращаемый тип из типа единственного 
аргумента вспомогательной функции. Эта техника широко применяется 
в стандартной библиотеке для таких утилит, как р\г_Гип, паке _раіг, 
тет_Рип, раск_іпѕегтег и многих других, вспомогательных функций, упро- 
щающих сложную и чреватую ошибками задачу специализации шаблона 
класса. 


Тема 58 | Перегрузка шаблонов функций 


Шаблоны функций могут быть перегружены другими шаблонами функ- 
ций и нешаблонными функциями. Эта возможность полезна, но ею часто 
злоупотребляют. 


Одним из основных отличий между шаблонами функций и нетаблонны- 
ми функциями является доступность неявных преобразований фактиче- 
ских параметров. Нешаблонные функции предоставляют широкий диапа- 
зон неявных преобразований своих аргументов – от встроенных преобра- 
зований (как целочисленное расширение) до пользовательских (неявные 
одноаргументные конструкторы и операторы преобразования). В случае 
с шаблонами функций, из-за того что компилятор должен логически вы- 
водить аргументы на основании их типов, проводятся только простейшие 
неявные преобразования, включая квалификацию внешнего уровня (на- 
пример, Т в сопѕї Т или сопѕї ТвТ), ссылку (например, ГвТ &) и разложение 
массива и функции в указатель (например, 1[42] вТ +). 


Практический эффект этой разницы в том, что шаблоны функций требу- 
ют намного более точного соответствия, чем нешаблонные функции. Это 
может быть хоропто, плохо или просто удивительно. Например, рассмот- 
рим следующее: 


тетр1ате <+урепате Т> 


моіа 9( Та, тр) {... } // этот 9 является шаблоном 
\019 9( сһаг а, свагЬ ) {... } // этот 9 - нет 

аы 

0( 12.3, 45.6 ); // шаблон 9 

9С 12385457) // не шаблон 9! 


Первый вызов с двумя аргументами типа йоир1іе мог бы быть сделан для 
сопоставления нешаблонной д путем неявного преобразования (оир1е 
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в сһаг (допускается, но не рекомендуется). Но точное соответствие доступ- 
но через создание экземпляра шаблона 0 с Т типа 0100016, поэтому выбира- 
ется шаблон. Второй вызов с аргументами типа 90и01е и іпї не будет да- 
вать соответствия шаблону 9, потому что компилятор не применит предо- 
пределенное преобразование из іпї в доц ]1е для второго аргумента (или из 
00ир1е в іпї для первого), чтобы логически вывести для Т тип 90] е (или 
117). Следовательно, вызывается нечлен 0 с применением так неуместно 
предопределенных преобразований д0и0]е и іпі в сһаг. 


Правильный выбор версии функции при наличии множества различных 
шаблонных и нешаблонных кандидатов — сложный процесс. Многие в дру- 
гих ситуациях надежные компиляторы С++ неправильно выбирают 
функцию или формируют несоответствующую ошибку. Это значит, что 
людям, работающим с нашим кодом, будет так же сложно понять, какая 
версия перегруженного шаблона вызывается. Ради всеобщего блага при 
использовании перегрузки шаблонов функций необходимо стремиться 
к максимальной простоте. 


«Просто» не значит безыскусно. В теме 57 «Логический вывод аргумен- 
тов шаблона» рассматривалась вспомогательная функция, позволяю- 
щая обойти трудную и чреватую ошибками специализацию сложного 
шаблона класса: 


Тетр1ате <Турепате А1, Турепаме А2, Турепаме В> 
с1аѕѕ РЕџп2 : рир1іс ѕїа: : ріпагу_ Ғипстіоп<А1, А2, В> { 
// см. реализацию в теме 57 «Логический вывод аргументов шаблона» 


}; 
Вместо того чтобы заставлять пользователей проводить специализацию 
этого монстра напрямую, мы предоставили вспомогательную функцию, 


которая выполнила логический вывод аргументов шаблона и специали- 
зацию: 


Тетр1ате <Турепате В, Турепате А1, Турепате А2> 
іп1іпе РЕџп2<А1, А2, А> такеРЕип( А (хр?) (А1, А2) ) 
{ геъигп РЕип2<А1, А2, В>(р#); } 


С точки зрения синтаксиса это очень сложный фрагмент кода, но он упро- 
щает работу пользователям. Теперь для функции, объявленной как 0001 
іѕбгеаїтег(іпї, іпі), они могут писать не РҒип2<іпі, іп, роо1>(іѕбгеаїег), 
а пакеРЕип(іѕбгеаїег). 


Конечно, нам хотелось бы предоставить механизмы и для унарных функ- 
ций: 


тетр1ате <+урепате А, Турепате В> 
с1аѕѕ РЕуп] : рир1іс $19: :џпагу Ғипсііоп<А, В> { 
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рир11с: 
ехр1ісії РЕип1( В (*#р) (А) ) : (р) {} 
В орегафог()( А а ) сопѕ+ 
{ геигп #р (а ); } 
ргімаїе: 
В (+Рр_) (А); 
}; 


и для вспомогательной функции: 


Тетр1ате <+урепате В, Турепате А> 

іпііпе РЕип1<А, А> такеРЕип( В (*р#) (А) ) 
{ геъигп РЕип1<А, В>(р#); 

} 


Прекрасный пример применения перегрузки шаблонов функций. Он прост 
в том смысле, что исключает неоднозначность вызываемой версии паке- 
РРип (одна для бинарных функций, другая для унарных функций). А одно 
имя для обеих функций делает эту функцию простой для запоминания 
и использования. 


Тема 59 | Концепция $ЕІМАЕ 


Используя логический вывод аргументов шаблона функции для выбора 
среди ряда перегруженных шаблонов функций и нешаблонных функций, 
компилятор может попытаться провести специализацию, которая приве- 
дет к ошибке. 


Тетр1афе <+урепате Т> уоіа #( Т ); 
Тетріате <+урепате Т> уоіа (Т * ); 
И. 


#( 1024 ); // создает экземпляр первой Ё 


Подстановка ненулевого целого для Т * во втором шаблоне функции # бы- 
ла бы неверной, но попытка подстановки не обусловливает формирова- 
ния ошибки, если обнаружена правильная подстановка. В данном случае 
создается экземпляр первого +, и ошибки не возникает. Таким образом, 
получаем концепцию «неудачная подстановка не является ошибкой» 
(Заза оп КаПоге 13 Моё Ап Еггог – ЗЕТМАЕ), введенную Вандевурдом 
(Уапдеуоог4е) и Джозаттисом (3031413). 


ЗЕПХАЕ - важное свойство, потому что без него было бы сложно перегру- 
жать шаблоны функций. Без него сочетание логического вывода аргумен- 
тов и перегрузки давало бы огромное количество недопустимых вариан- 
тов использования в наборе перегруженных шаблонов функций. Но БЕ[- 
МАЕ также ценна как техника метапрограммирования. 


Вспомним функцию 1І5Рїг, разрабатываемую в теме 52 «Создание специа- 
лизации для получения информации о типе». Чтобы выяснить, является 
ли неизвестный тип указателем некоторого рода, там применялась час- 
тичная специализация. Для достижения того же результата можно вос- 
пользоваться БЕТМАЕ. 


Туреде{г спаг Тгие; // ѕіғео#(Тгие) == 1 
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ТуредеЁ ѕїгисї { сһаг а[2]; } Ра1$е; // ѕігео#(Ға1ѕе) > 1 
ыы 

Тетр1афе <+урепате Т> Тгие іѕРіг( Т * ); 

Ра1зе іѕРїіг( ... ); 


Њае?іпе іѕ рїіг( е ) (ѕілео#(іѕРіг(е))==5ігео?(Тгие)) 


Здесь іѕ_ ріг позволяет выяснить, является ли выражение указателем, ис- 
пользуя логический вывод аргументов шаблона функции и 5ЕІЧАЕ. Если 
выражение е - указатель, компилятор выберет функцию 15Р\г; в против- 
ном случае будет выбрана нешаблонная функция іѕРіг с пропущенным 
формальным параметром. ЅЕІЧАЕ гарантирует, что попытка сопоставить 
шаблон іѕРїг с неуказателем не приведет к ошибке компиляции. 


Еще одна особенность этого примера связана с применением оператора 
5176о# в макросе іѕ ріг. Обратите внимание, что функции іѕРїг нигде не 
определены. Это правильно, потому что они фактически никогда не вы- 
зываются. Появление вызова функции в выражении $17е0{ заставляет 
компилятор осуществлять логический вывод аргументов и сопоставление 
функций, но он не вызывает функцию. Оператор $17601 интересует только 
размер возвращаемого типа функции, которая могла бы быть вызвана. 
Тогда по размеру возвращаемого типа можно понять, какая функция бы- 
ла выбрана. Если компилятор выбрал шаблон функции, выражение е – 
указатель. 


Нам не пришлось создавать специализации для константных указателей, 
изменяемых указателей и константных изменяемых указателей, как для 
функции 1Т5Р{г, реализуемой с помощью частичной специализации шабло- 
на класса. При логическом выводе аргументов шаблона функции компи- 
лятор проигнорирует су-квалификаторы «первого уровня» (сопѕї и уо1а- 
111е), как и модификаторы ссылок (см. тему 58 «Перегрузка шаблонов 
функций»). 


Не надо беспокоиться и о том, что пользовательский тип, имеющий опе- 
ратор преобразования в тип указателя, будет ошибочно определен как 
тип указателя. При логическом выводе аргументов шаблона функции 
компилятор руководствуется очень ограниченным списком преобразова- 
ний в фактические параметры, и пользовательские преобразования в не- 
го не входят. 


Обратите внимание на сходство этой техники с применением частичной 
специализации шаблона с целью выявления информации типа в теме 52 
«Создание специализации для получения информации о типе». Там «ло- 
вушкой» был базовый шаблон, и для выявления необходимых вариантов 
применялись частичная или полная специализации. Здесь в роли ловуш- 
ки выступает функция с опущенными формальными параметрами, 
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а интересующие варианты фиксируются более строгими перегруженны- 
ми версиями ловушки. Кстати, частичная специализация шаблона клас- 
са и перегрузка шаблонов функций очень тесно взаимосвязаны с техниче- 
ской точки зрения. Фактически стандарт определяет алгоритм выбора 
для одного в терминах другого. 


После разбора приведенного выше примера 1$_р1г практически больше 
нечего сказать о технической стороне БЕТМАЕ. Однако существуют очень 
неожиданные способы использования этой простой методики для выяв- 
ления информации о типах и выражениях во время компиляции. Рас- 
смотрим некоторые (не совсем простые) примеры. 


Пусть нам требуется определить, является ли неизвестный тип классом: 


Тетр1афе <+урепате Т> 
ѕігисї 15С1а55 { 
Тетр1а+е <с1аѕѕ С> ѕїатіс Тгие 15С1а55( іпі С::* ); 
Тетр1афе <+урепате С> ѕіа+іс Ра1ѕе 15С1а55( ... ); 
епит { г = ѕілео#(1$С1а55<Т>::15С1а55<Т7>(0)) 
== 317е0Р(Тгие) }; 
}; 


Точность имеет значение, на этот раз механизм ЅЕІМАЕ инкапсулирован 
в шаблон класса 15С1а5$ и два шаблона функций перегружены как стати- 
ческие члены 1501а$$. Одна из функций принимает указатель на член 
класса в качестве формального параметра (см. тему 15 «Указатели на 
члены класса – это не указатели»). Литеральный нуль может быть пре- 
образован в указатель на член класса (даже для шаблона функции). Та- 
ким образом, если Т – класс, будет выбран первый 15С1а55. Если Т не 
класс, БЕГМАЕ проигнорирует ошибочное первое сопоставление и выбе- 
рет версию 1$С1аз$ с опущенным списком параметров. Как ис1$_р\г, про- 
веряя размер возвращаемого типа функции, можно понять, какая функ- 
ция была выбрана, и, следовательно, определить, является ли Т классом. 


Второй пример позаимствован у Вандевурда и Джозаттиса. Предполо- 
жим, необходимо узнать, имеет ли определенный тип класса вложенное 
имя типа «іёегаѓог». (Конечно, это можно применить для любого вложен- 
ного имени типа, не только для іїегаїог.) 


ТетрТате <с1а55 С> 

Тгие һаѕІтегаїог( +урепапе С: :1фегафог сопѕї * ); 

Тетр1афе <+урепате Т> 

Ға1ѕе һаѕІ+ега+ог( ... ); 

#деғіпе һаѕ ітега+ог( С )\ 
(ѕілео#(һаѕІегатог<0>(0) )==ѕіғео#(Тгие)) 


Данная функция һаѕ_іїегаіог идентична 15С1а55, но на этот раз осуществ- 
ляется доступ к вложенному имени неизвестного типа (см. тему 49 «Устра- 
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нение неоднозначности с помощью имени типа»). Если у С есть такой 
вложенный тип, можно будет преобразовать литеральный нуль в указа- 
тель на такой тип. В противном случае будет выбрана ловушка. 


И наконец, рассмотрим фокус Андрея Александреску (Ап@ге! А]ехапа- 
геѕси). Можно ли преобразовать Ті в Т2, имея два неизвестных типа, Ті 
и Т2? Обратите внимание, что механизм выберет и предопределенное, 
и пользовательское преобразования: 


Тетр1ате <Турепате Т1, Турепаме Т2> 
ѕігис СапСопмеге { 

ѕ+аїіс Тгие сапСопуегї( Т2 ); 

ѕ+аїіс Ға1ѕе сапбопуегі( ... ); 

ѕ+аїіс Т1 такет1(); 

епит { г = ѕіхео#(сапСопуегї( такет1() )) == ѕіхео#(Тгие) }; 
}; 


Как показала реализация Неар в теме 52 «Создание специализации для по- 
лучения информации о типе», часто гибкость или возможность предо- 
ставлять специальные реализации основывается на информации, кото- 
рая может быть статически выявлена во время компиляции. Используя 
ЗЕПХАЕ и другие методики метапрограммирования, можно задавать та- 
кие вопросы, как: «Является ли этот неизвестный тип указателем на тип 
класса, имеющий вложенный тип іїегаїог, который может быть преобра- 
зован в $14: :ѕігіпо?». 


Тема 60 | Универсальные алгоритмы 


Универсальный алгоритм – это шаблон функции, спроектированный та- 
ким образом, что может быть легко и эффективно настроен во время ком- 
пиляции соответственно контексту использования. Рассмотрим шаблон 
функции, не отвечающий этим стандартам и, следовательно, не являю- 
щийся полноценным универсальным алгоритмом: 


Тетр1афе <+урепате Т> 
уоіа ѕ1омЅогї( Т а[], іпї 1еп ) { 
ПОС ше т = 0 1 < айр зы )) // Для каждой пары 
ПОС ПЕ ] = № ] < Ш == ) 


Ш а] Ат // ...если порядок не соблюден. . 
1 аа а); // ...поменять местами. 
а[ј1 = а[1]; 
а[і] = тр; 


} 


Этот шаблон может служить для сортировки массива объектов при усло- 
вии, что для сравнения объектов может быть применен оператор < и они 
могут копироваться. Например, можно сортировать массив объектов 5ї гіпо 
из темы 12 «Присваивание и инициализация - это не одно и то же»: 


гіпо патез[] = { “ту”, “909”, “паз”, “Ееесе” }; 
СопзЕ іпі памез[еп = ѕілео#(патеѕ) /з17ео{(патез[0]); 
ѕ10м50гі( патеѕ, патеѕіеп ); // проведет сортировку. ..в конце концов! 


Первое нарекание на $10\50г{ (медленная сортировка) — слишком низкая 
скорость сортировки. Наблюдение верное, но простим ей скорость выпол- 
нения О(п?) и сосредоточимся лучше на универсальности. 
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Прежде всего можно заметить, что предложенная реализация переста- 
новки в $10\50г{ не идеальна для типа 5їгіпо (и многих других типов, если 
на то пошло). У класса 5їгіпо есть собственный член ѕмар, одновременно 
и более быстрый, и более безопасный, чем перестановка, выполняемая 
путем копирования во временный массив 51г1п9. Лучшим подходом при 
реализации будет просто выразить то, что имеется в виду: 


Тетр1афе <+урепате Т> 
уоіа ѕ10м50гі( Т а[], іп 1еп ) { 
Рог( іп 1 = 0; і < 1еп; ++і ) // Для каждой пары 
Ғог( іп ј = 1; ј < 1еп; ++] ) 
іР( а[}] < а[1] ) // ...если порядок не соблюден... 
ѕмар( а[3], а[1] ); // ...поменять местами. 
} 


Здесь по-прежнему не вызывается функция-член ѕмар класса 5%г1пд, но ес- 
ли у автора 5+г1п9 «все схвачено», то будет доступна функция-нечлен ѕмар: 


іп1іпе моіа змар( 51гіпо &а, Ѕігіпо &р ) 
{ а. ѕмар( Ы ); } 


А если в нашем распоряжении нет такого нечлена ѕмар? В этом случае си- 
туация ничуть не ухудшится, потому что так или иначе в итоге можно 
вызвать функцию ѕмар стандартной библиотеки, которая делает абсолют- 
но то же самое, что было прописано в исходной версии кода 510%50гі. Но 
все равно фактически мы остались в выигрыше, потому что новая реали- 
зация $10\50г{ короче, проще и понятнее. И, что еще важнее, если кто-то 
когда-нибудь реализует эффективную функцию-нечлен ѕмар для Ѕігіпо, 
улучшение будет подхвачено автоматически. С таким обслуживанием ко- 
да можно жить. 


Теперь рассмотрим сравнение элементов массива с помощью оператора <. 
Это, наверное, самый распространенный способ сортировки массива (от 
меньшего к большему). Но может потребоваться сортировать массив 
в убывающем порядке или как-нибудь иначе. Более того, сортировка мо- 
жет понадобиться массивам объектов, которые или не поддерживают опе- 
ратор <, или имеют несколько разных кандидатов, подобных оператору 
«меньше чем». Такой тип уже был представлен в теме 20 «Объекты- 
функции ТІ»: класс Ѕїаїе: 


с1аѕѕ офате { 
рир11с: 
Е 
іп рориТа+іоп() сопѕї; 
Ғ1оаї амеТетрЕ() сопѕї; 
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Подход, рассмотренный в теме 20 «Обзекты-функции 5ТГ», заключался 
в реализации функций и объектов-функций, которые могли бы использо- 
ваться вместо оператора <. Но этот подход эффективен, только если есть 
универсальный алгоритм принятия такого аргумента: 


Тетр1ате <Турепате Т, +урепате Сотр> 
уоіа ѕ1омЅогї( Т а[], іп 1еп, Сотр 1еѕѕ ) { 
Рог( іп і = 0; і < 1еп; ++) // Для каждой пары 
Ғог( іп ј = і; ј < Іеп; ++] ) 
іР( 2е55( а[5], а[1] ) ) // ...если порядок не соблюден... 


ѕмар( а[7], а[1] ); // ...поменять местами. 
} 
еъ 
бате ѕіаїеѕ[50]; 
а 


$1ом5огЕ( зтафез, 50, РорСотр() ); 


Если сортировка с помощью функции $10050гї с оператором < так широко 
применяется, наверное, неплохо было бы перегрузить 510и50гі, чтобы ее 
можно было вызывать как со специальной операцией сравнения, так 
и без нее. 


Наконец, всегда надо следовать соглашению, и это особенно полезно в слу- 
чае с универсальными алгоритмами. Можно критиковать $10\50г{ и за на- 
кладываемое на сортируемый аргумент ограничение — он должен быть 
массивом, но ведь есть множество других типов контейнеров или струк- 
тур данных, которые тоже может понадобиться сортировать. Если есть 
сомнения, посмотрите, как реализована стандартная библиотека: 


Тетр1ате <Турепате Рог, Турепате Сотр> 
уоіа ѕ1омЅогїі( Рог 0, Ғог е, Сотр 1е55 ) { 


Ғог( Рог і( 0 ); 1 != е; ++ ) // Для каждой пары 
Рог( Рог ј( і ); ј = е; ++] ) 
1Р?( 1655( *], *і ) ) // ...если порядок не соблюден... 
ѕ+а::ѕмар( *ј, *1 ); // ...поменять местами. 


} 


тетр1ате <+урепате Рог> 
уоіа ѕ10мЅ0гі( Рог 0, Роге ) { 


Ғог( Рог і( 0 ); і != е; ++ ) // Для каждой пары 
Рог( Рог ј( 1); ј = е; ++] ) 
іР( *ј < *і) // ...если порядок не соблюден... 
ѕ+а::ѕмар( *ј, *1 ); // ...поменять местами. 

} 

ка 

ѕ510::1151<5їаїе> ѕіаїеѕ; 

Ду 


ѕ10м50гі( ѕіа+еѕ. редіп(), ѕтатеѕ.епа(), РорСотр() ); 
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ѕ10м50гі( патеѕ, патеѕ+патеѕіеп ); 


Здесь неуклюжий интерфейс массива заменен на более стандартный и гиб- 
кий совместимый с ТІ, интерфейс итератора. Теперь можно спокойно 
вызывать удобный универсальный алгоритм 510050гї, а не простой шаб- 
лон функции. 


Один из важных уроков этого примера — сложное ПО практически всегда 
проектируется группой. По существу, ваш код должен проектироваться 
с учетом экспертной оценки коллег, но при этом оставаться максимально 
изолированным от изменений кода, находящегося вне вашего контроля. 
Улучшенный алгоритм $10\50г{ — хороший пример правильного проекти- 
рования. Он на максимально возможном абстрактном уровне описывает 
единственную абсолютно понятную операцию. Точнее, $10\50г{ осуществ- 
ляет алгоритм сортировки, а операции перестановки и сравнения переда- 
ет другим функциям, которые сделают эту работу лучше. Такой подход 
позволяет вам, (предполагаемому) эксперту сортировки, расширять свой 
алгоритм сортировки алгоритмом перестановки для типа элемента, раз- 
работанного кем угодно. Вы можете никогда не встречаться, но при пра- 
вильном подходе к проектированию можете сотрудничать так близко, 
как если бы работали на одном компьютере. Более того, если в будущем 
появится улучшенная реализация перестановки, $10\50гЁ подхватит 
улучшение автоматически и, вероятно, без вашего ведома. Как никогда 
раньше, неведение - сила. (Это заставляет нас вспомнить о правильном 
полиморфном проектировании; см. тему 19 «Команды и Голливуд».) 


Тема 61 | Мы создаем экземпляр того, 
что используем 


Как в С, так и в С++ объявленную функцию не надо определять, если она 
не вызывается (или если вы не вызываете ее адрес). Аналогичная ситуа- 
ция с функциями-членами шаблонов классов: если фактически функция- 
член шаблона не вызывается, ее экземпляр не создается. 


Конечно, это свойство очень полезно для сокращения размера кода. Если 
шаблон класса определяет много функций-членов, из которых использу- 
ются только две или три, то неиспользуемые функции не занимают места 
в программном коде. 


Еще более важное следствие из этого правила — можно специализировать 
шаблоны классов аргументами, которые были бы недопустимыми, если 
бы создавались экземпляры всех функций-членов. Из этого правила сле- 
дует, что можно создавать гибкие шаблоны классов, которые могут рабо- 
тать с массой разнообразных аргументов. Даже с теми аргументами, кото- 
рые могли бы обусловить ошибку при создании экземпляров некоторых 
функций-членов. Если эти приводящие к ошибке функции не вызывают- 
ся, их экземпляры не создаются, ошибки не возникает. Это согласуется со 
многими разделами языка программирования С++, где потенциальные 
проблемы не являются ошибками до тех пор, пока они не становятся ре- 
альными проблемами. В С++ запрещенные помыслы допускаются до тех 
пор, пока они не начинают реализовываться! 


Рассмотрим простой шаблон массива фиксированного размера: 


Тетр1ате <Турепате Т, іп п> 
с1аѕѕ Аггау { 
рир11с: 
Аггау() : а ( пем Т[п] ) {} 
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-Аггау() { де1еїе [] а; } 
Аггау( сопѕї Аггау & ); 
Аггау ёорега+ог =( сопѕі Аггау & ); 
уоіа ѕмар( Аггау &1һаї ) { ѕ+а: :ѕмар( а, їһа+.а_ ); } 
Т &орегаог []( іпї і ) { гефит а [1]; } 
сопѕЇі Т &орегатог []( іп і ) сопзі { гефигп а [1]; } 
роо1 орегафог ==( сопѕі Аггау &гћѕ ) соп; 
роо1 орегафог !=( сопѕі Аггау &гй$ ) сопѕї 
{ геигп ! (+1һіѕ==гһѕ); } 

ргімаїе: 

Т *а_; 
}; 


Поведение этого контейнера очень похоже на поведение предопределенно- 
го массива: те же обычные операции для индексации. Но здесь также пре- 
доставляются некоторые высокоуровневые операции, недоступные в пре- 
допределенных массивах, такие как перестановка и проверка эквивалент- 
ности (опущены операторы отношений, чтобы не занимать много места). 
Рассмотрим реализацию орегаїог==: 


Тетр1ате <Турепате Т, іп п> 
роо1 Аггау<Т, п>: :орегаог ==( сопѕї Аггау &іһаї ) сопѕі { 
Рог( іп і = 0; 1 < п; ++1 ) 
ТЕ (а [1] == +һа+.а [1]) ) 
гефтигп Га1$е; 
геїигп гие; 


} 


Известно, что оба сравниваемых массива имеют одинаковое число эле- 
ментов, поскольку они одного типа, и размер массива является одним из 
параметров шаблона. Поэтому требуется только провести попарное срав- 
нение элементов. Если хотя бы в одной паре элементы отличаются, объ- 
екты Аггау не равны. 


Аггау<іп, 12> а, р 


1 а == р ) // вызывается а.орегафог ==(0) 


Когда к объектам Аггау<іпї, 12> применяется операция ==, компилятор 
создает экземпляр Аггау<іпї, 12>: :орегафог==, компиляция которого про- 
ходит без ошибок. Если бы к объектам типа Аггау<1 пт, 12> не применялась 
операция == (или !=, вызывающая орегаїог==), не надо было бы создавать 
экземпляр этой функции-члена. 


Интересная ситуация возникает при создании экземпляра Аггау типа, в ко- 
тором не определена операция ==. Например, представим, что тип Сігс1е 
не определяет или не наследует орегаїог==: 
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Аггау<Сігс1е, 6> с, 49; // нет проблем! 


И 
©[3].9гам(); // ОК 


Пока все нормально. Операция == ни прямо, ни косвенно не применялась 
к объекту Аггау<Сігс1е, 6>, поэтому экземпляр функции орегаїог== не соз- 
давался, ошибки нет. 


1 с == а ) // ошибка! 


Теперь возникла проблема. Компилятор попытается создать экземпляр 
Аггау<Сігс1е, 6>::орегаїог==, а реализация функции попытается сравнить 
два объекта Сігс1е с помощью несуществующего оператора ==. Ошибка 
компиляции. 


Эта методика обычно используется при проектировании максимально 
гибких шаблонов классов. 


Обратите внимание, что этой идиллии не наблюдается в случае явного 
создания экземпляра шаблона класса: 


Тетр1а+е Аггау<Сігс1е, 7>; // ошибка! 


Директива явного создания экземпляра указывает компилятору создать 
экземпляр Аггау и все его члены с аргументами Сігс1е и 7. В результате 
при создании экземпляра Аггау<Сігс1е, 7>:: орегаїог== возникает ошибка 
компиляции. Ну, вы сами напросились... 


Тема 62 | стражи включения' 


В приложениях С++ используется много заголовочных файлов, и часто 
одни заголовочные файлы включают другие. В таких условиях часто за- 
головочный файл может быть косвенно включен в компиляцию несколь- 
ко раз. В больших сложных приложениях нередко один и тот же заголо- 
вочный файл встречается сотни раз в одной компиляции. Рассмотрим 
простой заголовочный файл Пдг2.!, включающий другой заголовочный 
файл һаг1.һ, и заголовочный файл һг3.һ, также включающий һагі.һ. Ес- 
ли и һг2.һ, и 19гЗ.П включены в один и тот же исходный файл, һагі.һ бу- 
дет включен в него дважды. Обычно множественные включения нежела- 
тельны и вызывают множество ошибок определения. 


По этой причине заголовочные файлы С++ практически везде использу- 
ют директивы препроцессора. Это предотвращает появление содержимо- 
го заголовка в компиляции более одного раза независимо от того, сколько 
раз фактически включен (#1пс1и9е) заголовочный файл. Рассмотрим со- 
держимое заголовочного файла Паг1. 1: 


#іғпаеғ НОВІ Н 

#аетіпе НОНТ_Н 

// фактическое содержимое заголовочного файла... 
Њепаі? 


При первом включении (#іпс1и0е) заголовочного файла һігі.һ в компиля- 
цию символ препроцессора НОВ1_Н не определен, поэтому условная дирек- 
тива препроцессора #і ?пде? («если не определен») делает возможной пред- 
варительную обработку директивы #іеѓіпе и остального содержимого за- 


1 «Стражи включения» (шс]а4е хиаг4з) – термин, автором которого является 
Бьярн Страуструп, создатель языка С++. 
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головочного файла. При втором появлении |0г1. в той же компиляции 
символ НОН1_Н определен, и #1Тп4еГ предотвращает повторное включение 
содержимого заголовочного файла. 


Эта техника будет работать, только если символ, используемый препро- 
цессором для заголовочного файла (в данном случае НОВ1_Н), ассоцииро- 
ван только с одним заголовочным файлом (в данном случае пдг1. |). По- 
этому важно установить стандарт, простое соглашение о присваивании 
имен, что обеспечит возможность образовывать имя символа, используе- 
мого в страже включения, из имени защищаемого заголовочного файла. 


Кроме предотвращения ошибок, стражи включения также помогают по- 
высить скорость компиляции за счет пропуска содержимого заголовоч- 
ных файлов, которые уже были транслированы. К, несчастью, на сам про- 
цесс открытия заголовочного файла, проведения оценки #111961 и поиск 
завершающего #епіі? в сложных ситуациях, когда большое количество 
заголовочных файлов многократно появляется в данной компиляции, 
может уходить очень много времени. В некоторых случаях избыточные 
стражи включения могут существенно ускорить дело: 


#1ғпде? НОА н 
#іпс1иае "һаг1.һ” 
непаі? 


Вместо того чтобы просто включить (#іпс1џйе) заголовочный файл, мы за- 
щищаем включение проверкой того же защитного символа, который задан 
в заголовочном файле. Такие стражи избыточны, потому что при первом 
включении заголовочного файла это же условие (в данном случае #і#піеѓ 
НОВ1_Н) будет проверено дважды – и перед #1пс1иде, и в самом заголовоч- 
ном файле. Однако при последующих включениях избыточный страж 
предотвратит выполнение директивы #1пс1и9е, предупреждая ненужное 
открытие и просмотр заголовочного файла. Избыточные стражи включе- 
ния не так распространены, как одиночные, но в некоторых случаях ис- 
пользование первых может существенно улучшить время компиляции 
больших приложений. 


Тема 63 | Необязательные ключевые слова 


Некоторые ключевые слова с точки зрения языка программирования С++ 
абсолютно необязательны, хотя по другим соображениям их наличие или 
отсутствие может быть спорным. 


Чаще всего источником путаницы становится необязательное использо- 
вание уігіџа1 в функции-члене производного класса, переопределяющей 
виртуальную функцию-член базового класса. 


с1аѕѕ Ѕһаре { 


рир11с: 
үігіџа1 у019 Чгам() сопѕі = 0; 
үігїџа1 уоіа го+ате( доир1е дедгееѕ ) = 0; 
үігіџа1 уоід іпуегї() = 0; 
ЕЕ 


}; 
с1аѕѕ В106 : рир1іс Ѕһаре { 

рир11с: 
үігіџа1 уоіа дгам() сопѕї; 
уо1іа го+а+е( доир1е ); 
уоіа 1пуегЕ() = 0 


ТР 


}; 


Функция-член 8106: :9гам переопределяет функцию гам (рисовать) базо- 
вого класса и, таким образом, является виртуальной. Ключевое слово не 
оказывает никакого влияния на смысл программы, и его совершенно спо- 
койно можно опустить. Всеобщее заблуждение в том, что пропуск ключе- 
вого слова уігіџа1 сделает невозможным дальнейшее переопределение 
в последующих производных классах. Это не так. 


с1аѕѕ ЅһагрВ1ор : рир11іс В106 { 
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рир1іс: 
уоіа готаїе( доир1е ); // переопределяет В1о6: : гоаїе 
Иа 

}; 


Обратите внимание, что ключевое слово уігіџа1 также можно опустить 
и при переопределении чисто виртуальной функции, как в В106: : 1п\егт. 
Наличие или отсутствие уігіџа1 в переопределяющей функции производ- 
ного класса полностью произвольно и не влияет на смысл программы. 
Никоим образом. 


Мнения по поводу того, хорошо ли опускать ключевое слово \1г{иа1 в пе- 
реопределяющей функции производного класса, разделились. Некото- 
рые специалисты утверждают, что незначащее \у1г{иа1 помогает задоку- 
ментировать природу функции производного класса для человека - чита- 
теля программы. Другие называют это лишней тратой усилий и считают, 
что это может привести к «случайному» превращению непереопределяю- 
щей функции производного класса в виртуальную. Неважно, какого мне- 
ния придерживаться, главное быть последовательным — или использо- 
вать ключевое слово уігіџа1 во всех переопределяющих функциях произ- 
водного класса, или везде опускать его. 


Ключевое слово ѕїаііс можно опускать при объявлении членов орегаїог 
пем, орега+ог де1ете, и их версий для массивов (см. тему 36 «Индивидуаль- 
ное управление памятью»), потому что эти функции неявно статические. 


с1аѕѕ Напа1е { 
рир11с: 
үоіа *орега+ог пем( ѕіхө_ї ); // неявно статическая 
ѕіаіс №019 орегаїог де1еіе( уоіа * ); 
ѕіаіс №019 *орегафог пем[ ]( ѕіғе ї ); 
уоіа орегаїог ае1ете[ ]( уоіа * ); // неявно статическая 
}; 


Некоторые специалисты утверждают, что лучше всего быть точным и все- 
гда явно объявлять эти функции статическими. Другие думают, что если 
пользователь программы на С++ не знает о неявной статичности этих 
функций, он не должен использовать или обслуживать код. Указывать 
здесь ключевое слово ѕіаїіс – пустая трата сил. Программа не место для 
размещения шпаргалок по семантике языка. Как и с уігіџа1, какую бы 
позицию вы ни занимали относительно ѕїаїіс, важно быть последова- 
тельным. Или все эти четыре функции должны явно объявляться стати- 
ческими, или ни одна из них. 


В заголовке шаблона ключевые слова їіурепапе и с1аз$ являются взаимоза- 
меняемыми. Они обозначают, что параметр шаблона является именем ти- 
па, и ничем не отличаются. Однако в коде опытных программистов на 
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С++ +урепапе сообщает читателю-человеку, что аргумент шаблона может 
быть любого типа, а с1а55 — что аргумент типа должен быть классом. 


тетр1ате <+урепате Іп, +урепате Оџ+> 
Ои сору( Іп реодіп, Іп епа, Ои геѕи1ї ); 


Тетр1ате <с1а55 Сопіаіпег> 
уоіа геѕіғе( Сопаіпег &сопїаіпег, іпї пем5126 ); 


В прежние времена при помощи ключевого слова гедіѕїег программист 
мог «намекнуть» компилятору, что переменная (по мнению программи- 
ста) будет активно использоваться и поэтому должна быть помещена в ре- 
гистр. Также не допускалось получение адреса переменной, объявленной 
с ключевым словом гедіѕїег. Однако вскоре создатели компиляторов по- 
няли, что их коллеги, занимающиеся разработкой программ, не имели 
никакого понятия о том, какие переменные должны храниться в регист- 
ре. Поэтому теперь компиляторы полностью игнорируют такие предло- 
жения программистов. В С++ ключевое слово гедіѕіег вообще никак не 
влияет на смысл программы и обычно не меняет ее эффективности. 


Ключевое слово аџїо может служить для обозначения того, что автомати- 
ческая переменная (аргумент функции или локальная переменная) явля- 
ется автоматической. Не стоит с ним возиться. 


Чтобы быть до конца честным, отмечу, что и гедіѕіег, и аџїо могут устра- 
нять неоднозначность синтаксиса, когда код написан особенно скудно. 
Правильным подходом в таких случаях будет написать лучший код, по- 
зволяющий обойтись без этих ключевых слов. 


Библиография 


А]ехапагезса, Апаге!. Мо4егп С++ "Реѕієп. Айаіѕоп-Уезѕ1еу, 2001.1 
Реміһигѕі, Ѕёерһер С. С++ Сосйаз. Аайіѕоп-Мезѕ]еу, 2003. 


Сатта, Егісһ, БКісһага Нет, Баірһ Јоһпѕоп, апа Јоһп У1іѕѕійеѕ. Ре- 
яп Раїііегпѕз. Аайіѕоп-Уеѕ1еу, 1995.2 


оз, №ісо1аі М. Тле С++ 8ѓіапаага Гіргагу. Аааіѕоп-Уеѕ1еу, 1999. 
Меуегз, Ѕсоїї. Еѓѓесііре С++, Тһіга Еаіћһіоп. Аадіѕоп-Ұеѕ1еу, 2005. 
Меуегѕ, Ѕсоі. Еѓѓесііре ТІ. А9а1зоп-Уезеу, 2001. 

Меуегѕ, Ѕсоїї. Моге Е Ёесное С++. Аадіѕоп-Уеѕ1еу, 1996. 

БиЦег, НегЬ. Ехсерііопаї С++. Аадіѕоп-Уеѕ1еу, 2000.3 

БиЦег, Негр. Моге Ехсерііопа! С++. Ада1зоп-У\Уезеу, 2002.4 


. ЗоЌег, НетЪ. Ехсерііопаі С++51уе. Аййіѕоп-Меѕ1еу, 2005. 
. ЗаЦег,Неф, апа Апаге! АІехапӣгеѕси. С++ Сойіпє бапдагаз. Аааі- 


ѕоп-Мезѕ1еу, 2005.5 


. Уапаеуоогае, "Рауіа, апа №со]а1 М. Јоѕибіѕ. С++ Тетріаїеѕ. Айаіѕоп- 


УМезеу, 2003. 


. \Пзоп, Ма ем. Гтрегѓесі С++. Аадіѕоп-Ұеѕ1еу, 2005. 


А. Александреску «Современное проектирование на С++», Вильямс, 2002. 


Э. Гамма, Р. Хельм, Р. Джонсон, Дж. Влиссидес «Приемы объектно-ориенти- 
рованного проектирования. Паттерны проектирования», Питер, 2001. 


Г. Саттер «Решение сложных задач на С++», Вильямс, 2002. 
Г. Саттер «Новые сложные задачи на С++», Вильямс, 2005. 


Г. Саттер, А. Александреску «Стандарты программирования на С++», Виль- 
ямс, 2005. 


Алфавитный указатель 


Символы 


(), круглые скобки 
группировка 
в объявлениях, 70 
с операторами указатель на член, 68 
оператор вызова функции, 68 
. (точка, звездочка), оператор указатель 
на член, 68 
—>* (тире, угловая скобка, звездочка), 
оператор указатель на член, 68 


А 


АВС (абстрактный базовый класс), 115 
арог+, функция, 118, 136 
АПГ, (поиск, зависимый от типов 
аргументов), 97 
ацёо ріг, указатель 
в качестве элементов контейнера, 144 
описание, 144 
перегрузка операторов, 143 
преобразования, 144 
сравнение с умными указателями, 144 
ссылки на массивы, 144 


С 


Сігс1е, класс 
ковариантные возвращаемые типы, 
112 


указатели 
на функции-члены, 67 
на члены класса, 66 


Е, 
ехіё, функция, 118, 136 


б 
сеі/ѕеї, интерфейсы, 20 


н 


Напаіе 
ограничение на размещение в куче, 
119 
операции копирования, 59 
индивидуальное управление памятью, 
124 
Неар 
алгоритмы, 151 
явная специализация шаблона класса, 
154 


Ј 


Јауа и С++, сравнение, 52 


о 


орегафог а@ефе 
обычная версия, 124 
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индивидуальное управление памятью, 

125 
орегафог пе 

обычная версия, 125 

синтаксис размещения пеу, 122 

сравнение с оператором пез, 120, 123, 
139 

индивидуальное управление памятью, 
125 


Р 


РОР (простые старые данные), 53 


о 


О\УТАМ (диаШбу Ұііһои+ А Маше – 
качество без названия), 97 


К 


ВАП («получение ресурса есть 
инициализация»), 135-188 
ЕТТІ (информация о типе на этапе 
выполнения) 
для безопасного нисходящего 
приведения, 46 
для запроса возможностей, 101 
затраты на этапе выполнения, 46 
неправильное использование, 108 


5 


БЕПМАЕ («неудачная подстановка 
не является ошибкой»), 205 
макрос препроцессора 
разЦегафог, 204 
13 ріт, 202 
шаблон класса 
СапСопуег+, 205 
ІѕС1аѕѕ, 204 
Ѕһаре 
ковариантные возвращаемые типы, 
112 
указатели 
на функции-члены, 67 
на члены класса, 66 


БТІ, (стандартная библиотека шаблонов), 


29- 31 


А 


абстрактный базовый класс 
АВС, 117 
Асіоп, 79 
Еипе, 75 
БКоПарЫе, 100 
абстрактный тип данных, 19 
абстракция данных, 20 
Александреску, Андрей, 17, 205 
альтернативные имена объектов, 32 
см. псевдонимы, ссылки 
анонимные пространства имен, 93 
аргументы, шаблоны, 150 
арифметика адресов, 145 
арифметика указателей, 37, 148 
шаблон функции 
ргосеѕѕ 24, 37 
ѕеё 24, 34 


Б 


базовые классы 
абстрактные базовые классы, 
создание, 117 
полиморфные, 24 
превращение в абстрактные, 117 
рекомендации по реализации, 88 
функция-член, определение, 88 
Шаблонный метод, 88 
базовые шаблоны, 150 
ЗЕПМАЕ, 203 
создание 
специализации для получения 
информации о типе, 173 
экземпляра, 150 
специализация, 150 
частичная, 155, 177 
членов, 159 
явная, 154, 177 


безопасность, копирующее присваивание, 


59 
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221 


Вандевурд, Давид, 205 
виртуальное 
копирование, присваивание, 60 
наследование, компоновка класса, 54 
виртуальные 
конструкторы, 107 
указатели на функции, 76 
функции, компоновка класса, 52 
вложенные имена, шаблоны, 170 
вспомогательная функция, 198, 200 
встраиваемые функции, указатели на, 62 
встроенная информация о типе, 180 
вывод аргументов шаблона, 198 
выравнивание указателя на класс, 68, 
104, 112 
выражения, добавление/удаление 
квалификаторов 
сопві, 45 
уса е, 45 
высвобождение памяти, занимаемой 
массивом, 128 
выход и уничтожение (ехії), 118, 136 
вычисление индексов массива, 87 
вычислительный конструктор, 56, 57 


г 


глобальная область видимости, 
пространства имен, 93 

графические формы, управление 
ресурсами, 187 


Д 


дескрипторы файлов, управление 
ресурсами, 135 

Джозаттис, Николай, 205 

директивы иѕіпе, 91 


Е) 


заголовочные файлы, многократное 
включение, 214, 217 
запросы возможностей, 102 
защита 
доступа, 95, 114, 117 
от многократных включений, 214 


игры с доступом 


аРипс, функция , 119 
М№оСору, класс, 114 
№Неар, класс, 119 
ОпНеар, класс, 119 


идиомы 


Һапа1е Љоду, 118 

КАП, 188 

аксиомы надежности, 131 

виртуальный конструктор, 106 

вычислительный конструктор, 57 

запрещение копирования, 114 

нарушение принципов операции 
копирования, 144 

объект-функция, 73 
ТГ, 83 

ограничение на размещение в куче, 
119 

«получение ресурса есть 
инициализация», 138 

получение текущего пеу Һапаіег, 63 

предположение о безопасности 
уничтожения, 183 

приближенное вычисление размера 
массива, 85 

проверка на наличие 
самоприсваивания, 60 

разделение кода во избежание ЕТТІ, 
101 

смысл применения оператора 
аупатіс саѕё к ссылке, 47 

создание абстрактного базового 
класса, 117 

сравнение результатов присваивания 
и инициализации, 59 

ссылка на формальный параметр типа 
указатель, 42 

суть присваивания, 59 

умный указатель, 148 

упорядочение кода в целях 
обеспечения надежности, 133 


имена, шаблоны, 150 
имя типа, неоднозначность, 165 
инициализация, 55 


возвращаемое значение функции, 55 
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объявление, 55 

передача параметров, 55 
перехват исключений, 55 
сравнение с присваиванием, 57 


интерфейсный класс, 75, 100 


Асійоп, 79 
Кипс, 75 
ВоПаШе, 100 


исключения 


К 


аТетр]а%еСоп4ехф, шаблон функции, 
130 

Ви Йоп: :зеАс10оп, функция-член, 133 

+, функция, 187 

ВезоигсеНап Те, класс, 135 

бігіпе::орегаїог =, функция-член, 182 

Тгасе, класс, 187 

Х::Х, функция-член, 130 

распределение памяти, 140 


квалификаторы, добавление/удаление 


сопѕ+, 45 
уо]ае, 45 


класс 


АВС, 117 

Асћіоп, 79 

Арр, 87 

В, 69, 84, 94 

ВІор, 215 

Виіќоп, 77, 79 

С, 65 

Сара цу, 100 

СігеІе 
запросы возможностей, 101 
ковариантные возвращаемые типы, 

112 

указатели на функции-члены, 67 
указатели на члены класса, 66 

СігсІеЕаіфог, 112 

СопбаіпегТгаіёѕ<сопѕ+ сһаг *>, 183 

СопёаіпегТгаіїѕ<ЕогеіспСоп+аіпег>, 
188 

р, 69, 85, 94 

Е, 95 

Етріоуее, 110 

Е, 73 


ЕогеієпСопќѓаіпег, 183 
Еипс, 75 
Нап е 
КАП, 135 
безопасные операции з\ар, 59 
необязательные ключевые слова, 
216 
ограничение на размещение в куче, 
118 
создание массивов, 127 
Неар<еһаг *>, 154 
Неар<сопѕё сһаг *>, 152 
ІѕУҰагт, 83 
Меа1, 106 
МуАрр, 88 
МуСощашег, 163 
МуНап4е, 124 
ММЕРипс, 75 
№ шоСору, 114 
№Неар, 119 
ОЪзегуеа В], 103 
ОпНеар, 119 
Р1ауМизѕіс, 79 
РорГезз, 82 
гер, 125 
ВезоигсеНап е, 135 
ВоПа Ме, 100 
5, 53 
Ѕһаре 
запросы возможностей, 100 
ковариантные возвращаемые типы, 
112 
необязательные ключевые слова, 
215 
сравнение указателей, 103 
указатели на функции-члены, 67 
указатели на члены класса, 66 
ЅһареЕаіёог, 112 
ЅһагрВіор, 215 
брарћећі, 106 
Заоаге, 101 
ббаѓе, 81, 207 
бітіпе, 55 
Биб]есф, 103 
Т, 54 
Тетр, 110 
Тгасе, 137 


Алфавитный указатель 


223 


У ее, 101 
Х, 51, 98 
интерфейсный, 101 
свойств, 185 
члена-шаблона, 167 
5115<Т>::М№оае, 167 
клонирование, 107 
клюква, 17, 178 
ключевое слово 
аџфо, 217 
гесіѕіег, 217 
уігбџа1, 217 
ковариантность, 167 
ковариантный возвращаемый тип, 112 
код каркаса, обратные вызовы, 78 
Команда, паттерн, 78 
компараторы, 81 
Рор1[еѕѕ, класс, 82 
рор[еѕѕ, функция, 81 
РігСтр, шаблон класса, 156 
ѕіт1.еѕѕ, функция, 153 
объекты-функции ТІ, в их качестве, 
88 
компоновка класса 
виртуальное наследование, 54 
виртуальные функции, 52 
ковариантные возвращаемые типы, 
118 
контрвариантность, концепция, 66 
присваивание и указатели таблицы 
виртуальных функций, 54 
смещения членов, 54 
сравнение указателей, 104 
«что вижу, тои имею», 52 
константные 
указатели, сравнение с указателями 
на константу, 40 
функции-члены 
изменение объектов, 49 
логически константные, 50 
отложенное вычисление, 49 
перегруженный оператор 
индексирования, 51 
смысл, 51 
конструкторы 
виртуальные, 107 
вызов, 122 


защищенные, 117 
надежность, 140 
описание, 140 
перегрузка операторов, 140 
синтаксис размещения пеү, 122 
контракт, базовый класс в качестве, 24 
контрвариантность, концепция, 66 
компоновка класса, 66 
указатели на 
функции-члены, 66, 68 
данные-члены, 66 
члены-шаблоны, 167 
контрольные следы, управление 
ресурсами, 185 
копирование, 39 
адрес неконстанты в указатель 
на константу, 39 
объектов классов, 53 
присваивание, 60 
создание, 60 
копирующее присваивание, функция- 
член 
Нап ]е: :орегафог =, 60 
Нап е: :з\уар, 59 
круглые скобки, () 
группировка 
в объявлениях, 70 
с операторами указатель на член, 68 
оператор вызова функции, 68 
куча, распределение и ограничение, 119 


Л 


логическая константность, 50 
логические вопросы, 83 
логический вывод аргументов шаблона, 
36 
шаблон функции 

сазѕё, 195 

такеРЕип, 198, 200 

тіпітит, 196 

гереа$, 197 

тегоОи+, 197 


М 


макрос препроцессора 
разЦегафог, 204 


224 


Алфавитный указатель 


іѕ рёг, 202 
массивы 
в качестве аргументов функций, 36 
объектов класса, 122 
разложение, 85 
распределение памяти, 128 
распределение/высвобождение 
ресурсов, 128 
сортировка, 207 
ссылки, 72 
аціо ріг, 144 
указателей, 41 
многомерные массивы 
арифметика указателей, 146 
операторы объявления функций 
и массивов, 70 
формальные параметры типа массив, 
87 
множественное наследование, 104 


н 


надежность 
аксиомы, 181 
безопасное уничтожение, 130 
исключения, 140 
конструкторы, 140 
обеспечение, 134 
оператор пет, 140 
перехват, 184 
синхронные исключения, 130 
формирование исключения при 
перестановке, 131 
функции, 134 
«не звоните нам, мы сами вам позвоним», 
78, 88 
неведение 
Јауа-программисты, 52 
обратные вызовы, 77 
подводные камни, 12 
полезные аспекты, 23, 30, 209 
тип объекта, 107 
шаблоны и, 171 
неоднозначность, устранение с помощью 
шаблона, 172 
нестатические функции-члены, 
указатели на, 62 


неудачная подстановка не является 
ошибкой (БЕІЧАР), 205 
нисходящее приведение, 45 
безопасное, 46 
информация о типе на этапе 
выполнения, 46 
новые операторы приведения, 44 


о 


обнародование соглашения, 181, 185 
обратные вызовы, 62, 77 
Асііоп, класс, 79 
ресЕогеіуепеѕѕ, функция, 63 
код каркаса, 78 
«не звоните нам, мы сами вам 
позвоним», 78 
объекты-функции в их качестве, 80 
определение, 77 
принцип Голливуда, 78 
указатели на функции, 63 
общение с другими программистами 
фуреаеф, 71 
абстракция данных, 20 
идентификаторы в объявлениях 
шаблонов, 188 
паттерны проектирования, 27 
перегрузка, 201 
сравнение с неведением, 209 
объекты 
Роду, 118 
альтернативные имена объектов, 32 
см. псевдонимы, ссылки 
виртуальные конструкторы, 107 
запросы возможностей, 102 
изменение, 49 
логического состояния, 48, 51 
интегрирование функций-членов с 


помощью объектов-функций, 48, 76 


классов, 52 
клонирование, 107 
копирование, 53 
запрещение, 114 
массивы объектов, 122 
ограничения типа, 114 
отложенное вычисление, 49 
полиморфные, 24 


Алфавитный указатель 


225 


размещение в куче, ограничение, 119 
с несколькими адресами, 104 
см. сравнение указателей 
с несколькими типами, 21 
см. полиморфизм 
свойства класса, 185 
создание на базе существующих 
объектов, 110 
структура и компоновка, 54 
управление с помощью ВАП, 138 
объекты-функции, 73 
библиотеки ТІ, 
в качестве компараторов, 88 
в качестве предикатов, 83 
логические вопросы, 83 
описание, 83 
в качестве обратных вызовов, 77, 80 
интегрирование с использованием 
функций-членов, 76 
класс 
Асіїоп, 79 
Е, 73 
Еипс, 75 
ІѕҰагт, 83 
ММЕипс, 75 
Р]ауМиз!с, 79 
РоргГезз, 82 
описание, 76 
шаблон класса 
МЕипс, 76 
РЕип1, 200 
РЕип2, 198, 200 
РігСтр, 156 
объявление указателей на функции, 61 
объявления иѕіпе, 92 
обычные орегафог пем и орегафог аее, 
124 
одномерные массивы в качестве 
формальных параметров, 36 
оператор 
* (звездочка), перегрузка, 142, 144 
—>, перегрузка, 142, 144 
сопѕі саѕі, 45 
дупатіс саѕё, 47 
пеу 
надежность, 140 
описание, 140 


перегрузка операторов, 140 
сравнение с орегафог пех, 120, 123, 
139 
гешпфегргеф саѕі, 46 
зфа{1с_сазф, 47 
операторные функции-члены, перегрузка 
операторов-нечленов, 99 
операторы объявления 
массивов, указатели, 72 
функций, указатели, 72 
операторы приведения 
с01$$ саз%, 45 
аупатіс_ саѕі, 47 
геіпегргеї саѕі, 46 
зфа{1с_сазф, 47 
квалификаторы 
сопѕё, добавление /удаление, 45 
уса е, добавление/удаление, 45 
типов, изменение, 47 
нисходящее приведение 
иерархия наследования, 47 
к ссылочному типу, 47 
от указателя к базовому классу, 46 
новые 
описание, 47 
сравнение со старыми, 44 
перекрестное приведение, 101 
сравнение старых с новыми, 44 
функциональный стиль, 44 
отложенное вычисление, 49 


п 


память 
размещение в куче, ограничение, 119 
индивидуальное управление памятью, 
125 
параметры, шаблоны, 150 
параметры-шаблоны шаблонов, 190 
паттерны проектирования 
микроархитектуры, 28 
оболочки, 27 
описание, 28 
основные части, 28 
Фабричный метод, 110, 113 
Шаблонный метод 
описание, 88 
сравнение с шаблонами С++, 86 
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перегрузка 
как средство общения с другими 
программистами, 201 
операторов, 29, 73 
сравнение с переопределением, 85 
функций, 21 
шаблонов функций, 199 
перегрузка операторов, 29, 73 
* (звездочка), 142, 144 
—>, 142, 144 
апфо_рёт, 148 
ӨТІ, (стандартная библиотека 
шаблонов), 29 
арифметика указателей, 148 
вызов функции, 73, 99 
индексирования, 51 
инфиксные вызовы, 99 
исключения, 140 
конструкторы, 140 
надежность, 129 
объекты-функции, 73 
ЭТГ, 82 
оператор пе\, 140 
поиск операторной функции, 99 
политики, 193 
синтаксис размещения пеу, 120 
сравнение с переопределением, 84 
умные указатели, 142 
перегрузка функций, 21, 50 
БЕПМАЕ, 202 
область видимости, 95 
перегруженный оператор 
индексирования, 51 
получение адреса, 62 
требуемые знания, 13 
указатели на перегруженные 
функции, 62 
универсальные алгоритмы, 208 
перегрузка шаблонов функций, 201, 205 
шаблон функции 
=, 199 
такеРЕип, 201 
перекрестное приведение, 101 
переменные, как избежать статического 
связывания, 93 
переопределение 
сравнение с перегрузкой, 85 


функции, ковариантные 
возвращаемые типы, 113 
поиск 
зависимый от типов аргументов (Арі), 
96, 97 
Кенига, 96 
операторной функции, 99 
полиморфизм, 24 
полиморфные базовые классы, 24 
политики, 194 
шаблон класса 
Атгауре1е+еРо1ісу, 193 
М№оре1еёеРо!ісу, 193 
Р+г"РеіеёеРо1ісу, 193 
Б+аск, 192 
полная специализация, 152 
«получение ресурса есть 
инициализация», 135-188 
пользовательские типы, присваивание, 57 
порядок инициализации, 33 
порядок создания, 138 
предикаты, 83 
объекты-функции ТІ, в их качестве, 
83 
преждевременное прекращение (арогі+), 
118, 136 
преобразования, аџёо ріг, 144 
принцип Голливуда, 78, 88, 209 
присваивание, 55 
511$6<Т>::орегафог =, член-шаблон, 
168 
Бігіпе::орегаѓог =, функция-член , 56, 
132 
безопасное копирование, 59 
виртуальное копирование, 60 
вычислительный конструктор, 57 
и указатели таблицы виртуальных 
функций, 54 
копирование, 60 
пользовательские типы, 57 
создание, 56 
сравнение с инициализацией, 57 
уничтожение, 57 
пространства имен 
анонимные, 98 
директивы иѕіпе, 91 
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имена 
импорт, 91 
объявление, 90 
объявления изшя, 92 
описание, 93 
повсеместная явная квалификация, 91 
псевдонимы, 92 
прототип, 107 
класс 
Асійоп, 79 
Сіге]е, 111 
Меа1, 106 
Р1ІауМизѕіс, 79 
Ѕһаре, 111 
Ѕраеће+і, 106 
псевдонимы, 92 


Р 


разложение 
массивы, 85, 41 
функции, 85, 82 

распределение памяти, массивы, 128 

распределители 
АпАПос, шаблон класса , 170 
АпАПос::геђіпа, член-шаблон, 171 
соглашение о повторном связывании, 

171 
руководители, ничем не обоснованный 
выпад в их сторону, 28 


С 


Сакамото, Куи (завуалированная ссылка), 
56 
свойства 
СопбаіпегТгаіёѕ<сопѕ+ сһаг *>, класс, 
188 
СопёаіпегТгаіїѕ<ЕогеіспСоп+аіпег>, 
класс, 188 
описание, 185 
соглашения, 181, 185 
специализация, 185 
шаблон класса 
Соп+аіпегТгаіёѕ, 182 
СопіаіпегТгаіїѕ< уесфог<Т> >, 185 
Соп+аіпегТгаіёѕ<сопѕ+ Т *>, 184 
Соп+аіпегТгаііѕ<Т *>, 184 


шаблоны, 185 
сеансы регистрации, управление 
ресурсами, 187 
семафоры, управление ресурсами, 187 
сетевые соединения, управление 
ресурсами, 185 
синтаксис размещения пеуг 
аррепа, функция, 122 
орегафог пеу, функция, 120 
смещение члена класса, 54 
соглашения, 81 
ТІ, (стандартная библиотека 
шаблонов), 29- 31 
аксиомы безопасности, 131 
анонимный временный объект- 
функция, 83 
в универсальном программировании, 
163, 180, 181, 193, 208 
многоуровневые указатели, 42 
о необязательности збайс, 216 
о необязательности у1гфла1, 216 
о повторном связывании для 
распределителей, 171 
о присваивании имен, 95, 214 
операции копирования, 58 
размещение константного 
квалификатора, 39 
свойства и обнародование, 181, 185 
сравнение с1аѕѕ и ќурепате, 216 
создание 
копирование, 60 
массивов, 128 
массивов типа Нап е, 127 
необязательные ключевые слова, 
216 
ограничение на размещение в куче, 
119 
операции копирования, 59 
индивидуальное управление 
памятью, 124 
присваивание, 56 
специализации для получения 
информации о типе, 173 
экземпляров 
шаблонные функции-члены, 212 
шаблоны, 150 
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специализация 
Неар<соп$ сһаг *>::рор, функция- 
член, 160 
Неар<сопѕё сһаг *>::риѕһ, функция- 
член, 153, 161 
БЕПМАЕ, 203 
для получения информации о типе, 
173 
частичная, 177 
членов, 159 
шаблонов, 16 
явная, 177 
сравнение 
Јауа и С++ 
интерфейсные классы, 100 
операторы объявления функций 
и массивов, 71 
поиск функции-члена, 95 
нешаблонных функций с шаблонами 
функций, 199 
ссылок с указателями, 82 
указателей, 104 
ссылки, 32 
инициализация, 34 
на константы, 84 
на массивы, 72 
на неконстанты, 34 
на функции, 72 
нулевые, 34 
описание, 34 
сравнение с указателями, 82 
стандартная библиотека шаблонов (ТІ), 
29-31 
старшинство операторов, указатели на 
функции-члены, 68, 70 
старые операторы приведения, сравнение 
с новыми, 44 
статическое связывание, как избежать, 93 
субконтрактор, производный класс 
в качестве него, 24 


т 


терминология 
константные указатели и указатели 
на константу, 40 
логический вывод аргументов 
шаблона, 195 


новые и старые операторы приведения, 
44 
оболочки, 27 
обычные указатели 
и указатели на функции-члены, 69 
и указатели на члены класса, 66 
оператор пе\ и функция орегафог пе\м, 
120, 123, 139 
перегрузка и переопределение, 85 
присваивание и инициализация, 57 
ссылки и указатели, 32 
указатели на константу и константные 
указатели, 40 
Шаблонный метод и шаблоны С++, 86 
шаблоны, 150 
члены-шаблоны, 167 


тип 


У 


информация о типе, 185 
встроенная, 180 

квалификаторы, изменение, 47 

свойства, 185 

элементов контейнера, определение, 
180 


указатели, 41 


см. также умные указатели 
вычитание, 147 

итераторы списков, 148 
массивы, 41 

многоуровневые, 41 

потеря информации о типе, 104 
разыменование, 65 

сравнение с ссылками, 32 
стеки, 177 

управление буферами, 41 
целые числа в их качестве, 147 


указатели на 


уоіа, 104 
данные-члены, 66 
константу 
преобразование в указатель 
на неконстанту, 40 
сравнение с константными 
указателями, 40 
неконстанту, преобразование 
в указатель на константу, 40 
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объявления массивов, 72 
операторы объявления функций, 72 
символы, 152 
указатели 
изменение значений указателей, 42 
описание, 48 
преобразование в указатель на 
константу, 43 
преобразование в указатель на 
неконстанту, 43 
преобразования, 43 
управление буферами указателей, 
42 
функции, 61 
виртуальные, 76 
встраиваемые, 62 
на перегруженные функции, 62 
обратные вызовы, 63 
объявление, 61 
описание, 63 
универсальные, 62 
функции-члены 
виртуальность, 68 
интегрирование с использованием 
объектов-функций, 76 
контрвариация, 66 
нестатические функции-члены, 62 
простой указатель на функцию, 68 
синтаксис описания, 68 
сравнение с указателями, 69 
старшинство операторов, 68, 70 
члены класса, сравнение с обычными 
указателями, 66 
умные указатели, 29, 141 
итераторы списков, 29, 148 
перегрузка операторов, 142 
сравнение с ацфо_рёг, 144 
шаблоны, 142 
универсальные алгоритмы, 209 
шаблонов функций, 209 
вывод аргументов шаблона, 198 
перегрузка, 201 
сравнение с нешаблонными 
функциями, 199 
универсальные указатели на функции, 62 
уничтожение 
КАП, 136 


ограничение на размещение в куче, 


118 
порядок, 138 
присваивание, 57 
управление ресурсами, 135 
устранение неоднозначности 
для имени типа, 165 
ключевое слово 
апфо, 217 
гесіѕіег, 217 
шаблоны, 172 


Ф 


Фабричный метод, 110 
Сите, класс, 112 
Етр]оуее, класс, 110 
Ѕһаре, класс, 112 
Тетр, класс, 110 
формальные параметры массива, 37 


функции 
аЕипс, 92, 119 
аррепа, 122 


ресЕогеіуепеѕѕ, 63 

сІеапирВиѓ, 122 

?, 187 

ћропассі, 74 

=, 199 

сео, 109 

іпёертгаќе, 75 

орегафог пеу, 120 

рор[еѕѕ, 81 

зсапТо, 42 

ѕотеЕипс, 117 

Быт: :орегафог +, 57 

ѕітГеѕѕ, 158 

зуар, 207 

выбор правильной версии, 200 

массив как тип формального 
параметра, 85 

многоуровневые указатели, 41, 48 

разложение, 85, 82 

создания массива, 119 

ссылки на, 72 

статическое связывание, 
как избежать, 93 
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функции-члены 

Арр::ѕіагћир, 87 

Воќоп::ѕеёАсііоп, 183 

Еір::орегаёог (), 78 

Нап е::орегафог =, 60 

Нап е: :орегафог еее, 125 

Нап е: :орегафог пеу, 125 

Напаіе::ѕуар, 59 

Неар<сопѕі сһаг *>::рор, 160 

Неар<сопѕё сһаг *>::риз, 153, 161 

бігіпе::орегаїог =, 56, 132 

Бігіпе::Ббігіпо, 57 

Х::сефУаше, 50 

Х:лпетЕипс2, 98 

Х::Х, 130 

интегрирование объектов-функций, 76 

ошибки сопоставления функций, 95 

поиск, 95 

роли, 87 

создания массива, 127 

указатели на 
виртуальность, 68 
интегрирование с использованием 

объектов-функций, 76 

контравариация, 66 
простой указатель на функцию, 68 
синтаксис описания, 68 
сравнение с указателями, 69 
старшинство операторов, 68, 70 

шаблоны, 169 

функциональный стиль, 44 


Ц 


целые числа как указатели 
арифметика указателей, 147 
новые операторы приведения, 44, 46 
синтаксис размещения пех, 120 


Ч 


частичная специализация, 155, 177, 185 
Неар<Т *>::риѕһ, шаблонная 
функция-член, 156 
шаблон класса 
СопћаіпегТгаіїѕ< уесфог<Т> >, 185 
Соп+аіпегТгаіёѕ<сопѕ+ Т *>, 184 
Соп+аіпегТгаііѕ<Т *>, 184 


Неар<Т *>, 155 
ІѕАгтау, 176 
І5РСМ, 177 
ІѕРіт, 174 
члены 
еее, 125 
пем 
Нап е, класс, 124 
Нап ]е::орегафог пем, функция- 
член, 125 
МуНапа@е, класс, 124 
члены класса, сравнение указателей на 
них с обычными указателями, 66 
члены-шаблоны, 169 
АпАПос::геђіпа, 171 
51136<Т>::орегафог =, 168 
511$$<Т>::5 4 $$, 169 
511$$<Т>::50г$, 169 
«что вижу, то и имею», 52 


Ш 


шаблонные функции-члены 
Аггау<Т,п>::орегафог ==, 211 
Неар<Т *>::риѕћ, 156 
Неар<Т>::рор, 152 
Неар<Т>::риѕћһ, 152 
51151<Т>::етрёу, 166 
ббаск<Т>::риѕћ, 175 
Шаблонный метод 
Арр, класс, 87 
Арр::ѕіагіир, функция-член, 87 
МуАрр, класс, 88 
описание, 88 
сравнение с шаблонами С++, 86 
шаблоны, 87 
аргументы 
настройка, 155 
описание, 150 
вложенные имена, 170 
и неведение, 171 
имена, 150 
массив в качестве формальных 
параметров, 37 
настройка, 155 
параметры, 150 
свойства, 185 
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создание экземпляра, 150 
специализация 

свойства, 185 

терминология, 150 

частичная, 158, 177 

явная, 154, 177, 198 
сравнение шаблонов С++ 

с Шаблонным методом, 86 
умные указатели, 142 
устранение неоднозначности, 165, 172 
функции-члены, 169 


шаблоны классов 


АпАПос, 170 

Аттау, 210 
Атгауре1е+еРо1ісу, 193 
СапСопуегї, 205 
Сһескеар+г, 141 
Соп+аіпегТгаіїѕ, 182 
СоташегТга {< уесфог<Т> >, 185 
Сот{ашегТга{$<соп$% Т *>, 184 
Соп+аіпегТгаіїѕ<Т *>, 184 
Неар, 151, 159 
Неар<Т *>, 155 
Іѕ5Агтау, 176 

ІѕС1аѕѕ, 204 

Іѕ10+, 173 

[5РСМ, 177 

ІѕР+г, 174 

МЕипс, 76 
М№оре1ееРоісу, 198 
РГип1, 200 

РЕп0п2, 198, 200 
РігСтр, 156 
Р+г"Реі1еёеРо1ісу, 193 
РігТ4$+, 162 
РігУесќог, 42 
БКеааопу$ед, 180 
ЅСоПесйоп, 163 

бед, 179 

5115%, 166, 171 

ОбасК, 176, 189, 192 
Ұўгаррег1, 189 
У\У!гаррег2, 190 
УМ/гаррег3, 190 


шаблоны функций 


аТетр1аћеСоп%ех+, 180 
саѕё, 195 


ехігасёНеар, 154 
НШ, 163 

=, 199 

такеРЕип, 198, 201 
тіп, 196 

ргосезз, 87, 178, 180, 182 
ргосеѕѕ 24, 37 
гереаї, 197 

ѕеб 24, 34 

51оуог+, 209 

ѕуғар, 33, 58 
тегоОи+, 197 


шведский язык и профессиональное 


общение, 105 


Э 


элементы контейнера, 
аџіо ріг в их качестве, 144 


Я 


явная специализация, 154, 177 
класс 


СоташегТга{<с013% сһаг *>, 183 
СопёаіпегТгаіїѕ<ЕогеіспСоп+аіпег>, 


183 

Неар<сраг *>, 154 

Неар<сопѕ+ сһаг *>, 152 
шаблон класса 

Неар, 151 

Т$Ттф, 173 

явное создание экземпляра 

Атгау<Сігс1е,7>, 211 
Неар<аоџЫе>, 161 


